Documentation Suggestions for GPS to CAN V2 and SwitchBoard Manuals

[gruszczrob]

Hi everyone,

I have been going through the product documentation and found a few errors and missing descriptions in the datasheets for the GPS to CAN V2 and the SwitchBoard. I wanted to point them out so they can be corrected in future updates.

1. GPS to CAN V2 Manual (https://www.ecumaster.com/files/devices/gps2/gps2Manual.pdf)

• Duplicated Section: In the CAN section, the description for the Ecumaster Standard seems to be duplicated (copied twice).

• Value Range Error (Seconds): In the time structure description, minutes are correctly defined as 0-59 and hours as 0-23, but seconds are listed as 0-60. It should most likely be 0-59.

• Missing Bit Descriptions (Frame 0x401): In Byte 7 of the 0x401 frame, the descriptions for bits 3-7 are completely missing.

• Byte/Bit Allocation Mismatch (Frame 0x401 - Height): There is an inconsistency in the “Height” parameter. The manual states that it is a 16-bit value, but the actual byte allocation/layout makes it look like it occupies 24 bits.

2. SwitchBoard Manual (https://www.ecumaster.com/files/devices/switchboard/switchboardManual.pdf)

• Missing Bit Descriptions (Frame 0x642): In Byte 6 of the 0x642 frame, the descriptions for bits 4-7 are missing.

I am still reviewing the documentation and will update this thread if I spot anything else. Hopefully, this helps improve the datasheets!

Best regards,
gruszczrob

[mkuklis_ECUMASTER]

@gruszczrob

Duplicated Section: In the CAN section, the description for the Ecumaster Standard seems to be duplicated (copied twice).

There are descriptions for two different formats.
One is the Ecumaster format, the other is “Format M,” which is for Motec.

@gruszczrob

Value Range Error (Seconds): In the time structure description, minutes are correctly defined as 0-59 and hours as 0-23, but seconds are listed as 0-60. It should most likely be 0-59.

That is not a mistake.
This is for “leap second,” which is used in the UTC time format to synchronize it.

@gruszczrob

Missing Bit Descriptions (Frame 0x401): In Byte 7 of the 0x401 frame, the descriptions for bits 3-7 are completely missing.

There is no description for those bits because they are currently unused.

@gruszczrob

Byte/Bit Allocation Mismatch (Frame 0x401 - Height): There is an inconsistency in the “Height” parameter. The manual states that it is a 16-bit value, but the actual byte allocation/layout makes it look like it occupies 24 bits.

Again, no mistake here.
You seem to overlook the fact that not every bit/byte in a CAN frame has to be used.
“Height” channel is a 16-bit value, and byte 4 of that frame is unused.

@gruszczrob

Missing Bit Descriptions (Frame 0x642): In Byte 6 of the 0x642 frame, the descriptions for bits 4-7 are missing.

Unused.

[gruszczrob]

Thanks for the detailed clarifications!

Regarding the leap second (0-60) – that makes perfect sense now, thank you for explaining. My mistake!

However, I would like to clarify a few points:

• Duplicated Section (ID+4): If you look closely at the screenshot I attached, the header “Ecumaster output ID+4 (default: 0x404)” and the exact same UTC table are literally printed twice, one right after another (Im preaty sure that they are just duplicated). If one of them was supposed to be “Format M” (Motec), it seems the wrong table/header was copy-pasted by mistake during editing, because both tables currently show identical Ecumaster data.

• Unused Bits / Bytes (Height & Frame 0x642): I understand that not every bit or byte has to be used. My point is that leaving them completely blank or missing from the table creates confusion for the end-user (it looks like a typo or missing data). It would be much better and cleaner to explicitly label them as “Unused” or “Reserved” in the manual so the developer knows exactly what to expect.

Additionally, I wanted to report a separate issue regarding the 3D models:

• EMU Black / Classic STP File: There appears to be a physical dimension error in the STP 3D model for the EMU. One of the dimensions is incorrect and measures exactly 4 mm too small compared to the actual physical unit. Could you please double-check this with the hardware team and update the 3D model?