Raymarine's Micronet

[tty]

But how did you find them, from a microcompass or racemaster ?

I only have a dual display. I broke the traces between my hull transmitter's mcu and cc1000 so I can drive the radio from an esp32. I found those types by brute forcing 40ish data packets a second and seeing what got displayed.

03|03|05|25|30

That helped a lot. I didn't know there was a 0x03/single byte data packet. I searched all the 0x04/0x06/0x0a's but never thought to look for 0x03's. I modified my search and this is my current list. Still missing lat/long. It's possible the display does some sanity checking on the data which would make it very hard to find. Maybe I'll set something up to sweep 0x09 with different values as it's an unknown in the middle of position data. Other then that I think I have everything.

0x01 - 06 byte Speed
0x02 - 12 byte Trip/Log
0x03 - 05 byte Temp
0x04 - 06 byte Depth
0x05 - 06 byte App Wind Speed
0x06 - 06 byte App Wind Dir
0x07 - 06 byte HDG
0x08 - 08 byte SOG/COG
0c0A - 12 byte BTW
0x0B - 06 byte XTE
0x0C - 06 byte Time
0x0D - 07 byte Date
0x18 - 06 byte VMG-WP
0x1B - 06 byte Battery
0x1F - 08 byte DTW

 

[Rodemfr]

I only have a dual display. I broke the traces between my hull transmitter's mcu and cc1000 so I can drive the radio from an esp32. I found those types by brute forcing 40ish data packets a second and seeing what got displayed.

03|03|05|25|30

That helped a lot. I didn't know there was a 0x03/single byte data packet. I searched all the 0x04/0x06/0x0a's but never thought to look for 0x03's. I modified my search and this is my current list. Still missing lat/long. It's possible the display does some sanity checking on the data which would make it very hard to find. Maybe I'll set something up to sweep 0x09 with different values as it's an unknown in the middle of position data. Other then that I think I have everything.

0x01 - 06 byte Speed
0x02 - 12 byte Trip/Log
0x03 - 05 byte Temp
0x04 - 06 byte Depth
0x05 - 06 byte App Wind Speed
0x06 - 06 byte App Wind Dir
0x07 - 06 byte HDG
0x08 - 08 byte SOG/COG
0c0A - 12 byte BTW
0x0B - 06 byte XTE
0x0C - 06 byte Time
0x0D - 07 byte Date
0x18 - 06 byte VMG-WP
0x1B - 06 byte Battery
0x1F - 08 byte DTW

Awesome work ! This is indeed a powerful way to explore the protocol. I added these parameters to Micronet's description on Github.
For lat/lon, I will use the SD card of my Teensy board to log all Micronet traffic I receive. I might cross the path of a boat with the NMEA converter this summer. This year, I will navigate close to big Marina's

By the way, have you the description of the data coding (i.e. Speed is an integer multiplied by 10, etc.) ? I don't have this information for HDG, SOG/COG, BTW,XTE, Time, Date & VMG-WP.

I will start to code to the transmission part of the SW this evening, but this might be difficult to achieve the same success than you as an "autonomous" device. I may have to go through the pairing sequence and to understand it. I suspect that it will be harder than decoding display data packets.

Apart from that, I connected an UBlox neo M8N to my teensy, and I can now insert the GPS NMEA sentence inside the NMEA stream created from Micronet's data. I have all I need to have OpenCPN fully aware of my boats parameters. With your latest discoverings, we can even imagine sending back GPS data to Micronets displays.

 

[BMP_Express]

... might cross the path of a boat with the NMEA converter this summer. This year, I will navigate close to big Marina's ...

If you're near Cowes let me know! I've a boat down there with a Tacktick system feeding a T122 and onto a Quark Elec QK-A031 multiplexing that Tacktick data with AIS from our transponder onto the wifi. Currently I'm making my own mast numbers display using a raspberry Pi and 7" screen connecting to the TCP/IP from the QK box and displaying it.

If I can get that to work I'd be keen to try and get it to read from the Micronet directly. Although I'm very much an amateur with these things and what you've done sounds fairly complicated, I'd be keen to help out and will be about in Cowes a lot of the weekends this summer.

 

[Rodemfr]

If you're near Cowes let me know! I've a boat down there with a Tacktick system feeding a T122 and onto a Quark Elec QK-A031 multiplexing that Tacktick data with AIS from our transponder onto the wifi. Currently I'm making my own mast numbers display using a raspberry Pi and 7" screen connecting to the TCP/IP from the QK box and displaying it.

If I can get that to work I'd be keen to try and get it to read from the Micronet directly. Although I'm very much an amateur with these things and what you've done sounds fairly complicated, I'd be keen to help out and will be about in Cowes a lot of the weekends this summer.

Thanks BMP_Express,
I would love to come to Cowes, but I'm in south Britanny, that's too far for my small coastal gaff cutter.
I'm very interested in your building of an RPi based display. That's something I will probably investigate after the Micronet's story. For now, I'm using a Arduino board, that's easier, but I'm thinking to switch later to a Raspberry version of this decoder, with a specific kernel module. This way, just connecting a CC1101 board to RPi will allow it to autonomously receive data from the Micronet navigation devices.

 

[BMP_Express]

Thanks BMP_Express,
I would love to come to Cowes, but I'm in south Britanny, that's too far for my small coastal gaff cutter.

Yeah I can imagine there are closer boats to you which would be keen to help out!

The plan is to get the TCP link working and setup a basic server setup which writes the HTML code for a local web page displaying the information. When the Pi boots it'll run the python script to the server and open the web page fullscreen to display the info. The python script that generates the data could relatively easily be changed to decode the tacktick data too I think. The tricky bit I thought was connecting to the tacktick network that you guys seem to have done here.

I'lll post in here how I get on with the project as it might be useful to people.

 

[Rodemfr]

I only have a dual display. I broke the traces between my hull transmitter's mcu and cc1000 so I can drive the radio from an esp32. I found those types by brute forcing 40ish data packets a second and seeing what got displayed.

03|03|05|25|30

That helped a lot. I didn't know there was a 0x03/single byte data packet. I searched all the 0x04/0x06/0x0a's but never thought to look for 0x03's. I modified my search and this is my current list. Still missing lat/long. It's possible the display does some sanity checking on the data which would make it very hard to find. Maybe I'll set something up to sweep 0x09 with different values as it's an unknown in the middle of position data. Other then that I think I have everything.

0x01 - 06 byte Speed
0x02 - 12 byte Trip/Log
0x03 - 05 byte Temp
0x04 - 06 byte Depth
0x05 - 06 byte App Wind Speed
0x06 - 06 byte App Wind Dir
0x07 - 06 byte HDG
0x08 - 08 byte SOG/COG
0c0A - 12 byte BTW
0x0B - 06 byte XTE
0x0C - 06 byte Time
0x0D - 07 byte Date
0x18 - 06 byte VMG-WP
0x1B - 06 byte Battery
0x1F - 08 byte DTW

lat & lon have been found ! Data coded on 7 bytes (3+3+1) !

0x09.LAT/LON
.....|09|09|FP|LA|.LAM.|LO|.LOM.|DI|FC|
.....LA.=.latitude.in.degrees.(integer.part)
.....LAM.=.minutes.of.latitude.*.1000
.....LO.=.longitude.in.degrees.(integer.part)
.....LOM.=.minutes.of.longitude.*.1000
.....DI.=.Flags.:.0x00/0x01.->.South/North
..................0x00/0x02.->.East/West

It was a pain to get this one : I injected fake packets by air with cc1101. Network master is very picky and does not accept them unless you really look like the real device. I had to first power-up the system will all my devices in range, and then to move the wind transducer out of range and to send packets with cc1101 at the same postion than him after the request from master.
It will not be easy to insert an Arduino in the system...

 

[tty]

Nice. I doubt your displays are rejecting the data. They just aren't getting it. Timing is critical as the radios listen only for 2 to 3 ms every second.

0x01, 0x0A, 0x8B, 0x60, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0xF9 <- this is a valid header. Everything beyond the network id, the message type and checksum is superfluous.

This is a typical rx cycle of a hull transmitter. It wakes just before if not during the main display's preamble and is back to sleep within .5 ms after the packet ends. You have that 500 us to send another preamble or else it goes to sleep. I've not captured the communication between chips in my dual display but from playing around with it I believe it waits a bit longer but still in the very low ms range.



I have to strike one data pin from the list but add another. I've not been able to reproduce VMGWP.
0x18 - 06 byte VMG-WP
0xFD - 08 byte timer stop/start/set
0x06, 0xFD, 0x05, 0x0A, 0x00, 0x00, 0x00, 0x12 <-- sets timer to 5 minutes 10 seconds.
Third bit is minutes, fourth is seconds, fifth and six unk/unused (maybe used on the race display), seventh byte is stop (0x00)/start (0x01)/maybe more.

The last two that need found are vmg-wp and ttg(eta).

 

[tty]

Here's the final list of verified pids with example/test packets that set the fields to 1.

0x01 - 06 byte Speed                0x04, 0x01, 0x05, 0x00, 0x64, 0x6E
0x02 - 12 byte Trip/Log             0x0A, 0x02, 0x05, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, 0x0A, 0x7F
0x03 - 05 byte Temp                 0x03, 0x03, 0x05, 0x02, 0x0D
0x04 - 06 byte Depth                0x04, 0x04, 0x05, 0x00, 0x0A, 0x17
0x05 - 06 byte App Wind Speed       0x04, 0x05, 0x05, 0x00, 0x0A, 0x18
0x06 - 06 byte App Wind Dir         0x04, 0x06, 0x05, 0x00, 0x01, 0x10
0x07 - 06 byte HDG                  0x04, 0x07, 0x05, 0x00, 0x01, 0x11
0x08 - 08 byte SOG/COG              0x06, 0x08, 0x05, 0x00, 0x0A, 0x00, 0x01, 0x1E
0x09 - 11 byte LAT/LONG             0x09, 0x09, 0x05, 0x01, 0x03, 0xE8, 0x01, 0x03, 0xE8, 0x00, 0xEF
0x0A - 12 byte BTW                  0x0A, 0x0A, 0x05, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x21
0x0B - 06 byte XTE                  0x04, 0x0B, 0x05, 0x00, 0x64, 0x78
0x0C - 06 byte Time                 0x04, 0x0C, 0x05, 0x01, 0x00, 0x16
0x0D - 07 byte Date                 0x05, 0x0D, 0x05, 0x01, 0x01, 0x01, 0x1A
0x12 - 06 byte VMG-WP               0x04, 0x12, 0x05, 0x00, 0x64, 0x7F
0x1B - 06 byte Battery              0x04, 0x1B, 0x05, 0x00, 0x0A, 0x2E
0x1F - 08 byte DTW                  0x06, 0x1F, 0x05, 0x00, 0x00, 0x00, 0x01, 0x2B
0xFD - 08 byte timer stop/start/set 0x06, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x04

TWDIR needs App Wind Speed, App Wind Dir, HDG
BEAUF needs App Wind Speed, App Wind Dir, HDG
MAG TWDIR needs App Wind Speed, App Wind Dir, HDG
HEAD/LIFT needs App Wind Speed, App Wind Dir, HDG (this one takes a little bit to fill in as its a running average)
VMG needs App Wind Speed, App Wind Dir, Speed
TRUE WIND SPEED needs App Wind Speed, App Wind Dir, Speed
TRUE WIND DIR needs App Wind Speed, App Wind Dir, Speed
ETA/TTG needs VMG-WP and DTW.

The way I'm timing transmissions is ignoring the first request from the display (it's what the stock hull transmitter did). Sending a data packet 500us after the second request which gets the data displayed and a 0x0b message from the display that I'm currently ignoring. Then changing the send wait time from 500us to 13ms. If I don't adjust the wait time the display doesn't see my packet. The stock hull transmitter only waited 2ms to send it's data.

Working theory is since I'm not replying correctly to the 0x0b packet the display gives my device the last transmitting slot. It still accepts data if I change the device's ID or type as long as I transmit during my assigned slot which is around 12ms to 14ms after the request. It's possible that skipping the first packet is part of how devices order themselves during network startup. NMEA converter answers the first packet and gets it's slot, hull transmitters the second, then probably wind vane on the 3rd.

I'm going to look into the 0x0b/0x0a interaction tomorrow. I'd like to get my esp to register as a nmea converter in the options->health menu. See if it bumps up my slot.

 

[Rodemfr]

Here's the final list of verified pids with example/test packets that set the fields to 1.

0x01 - 06 byte Speed                0x04, 0x01, 0x05, 0x00, 0x64, 0x6E
0x02 - 12 byte Trip/Log             0x0A, 0x02, 0x05, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, 0x0A, 0x7F
0x03 - 05 byte Temp                 0x03, 0x03, 0x05, 0x02, 0x0D
0x04 - 06 byte Depth                0x04, 0x04, 0x05, 0x00, 0x0A, 0x17
0x05 - 06 byte App Wind Speed       0x04, 0x05, 0x05, 0x00, 0x0A, 0x18
0x06 - 06 byte App Wind Dir         0x04, 0x06, 0x05, 0x00, 0x01, 0x10
0x07 - 06 byte HDG                  0x04, 0x07, 0x05, 0x00, 0x01, 0x11
0x08 - 08 byte SOG/COG              0x06, 0x08, 0x05, 0x00, 0x0A, 0x00, 0x01, 0x1E
0x09 - 11 byte LAT/LONG             0x09, 0x09, 0x05, 0x01, 0x03, 0xE8, 0x01, 0x03, 0xE8, 0x00, 0xEF
0x0A - 12 byte BTW                  0x0A, 0x0A, 0x05, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x21
0x0B - 06 byte XTE                  0x04, 0x0B, 0x05, 0x00, 0x64, 0x78
0x0C - 06 byte Time                 0x04, 0x0C, 0x05, 0x01, 0x00, 0x16
0x0D - 07 byte Date                 0x05, 0x0D, 0x05, 0x01, 0x01, 0x01, 0x1A
0x12 - 06 byte VMG-WP               0x04, 0x12, 0x05, 0x00, 0x64, 0x7F
0x1B - 06 byte Battery              0x04, 0x1B, 0x05, 0x00, 0x0A, 0x2E
0x1F - 08 byte DTW                  0x06, 0x1F, 0x05, 0x00, 0x00, 0x00, 0x01, 0x2B
0xFD - 08 byte timer stop/start/set 0x06, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x04

TWDIR needs App Wind Speed, App Wind Dir, HDG
BEAUF needs App Wind Speed, App Wind Dir, HDG
MAG TWDIR needs App Wind Speed, App Wind Dir, HDG
HEAD/LIFT needs App Wind Speed, App Wind Dir, HDG (this one takes a little bit to fill in as its a running average)
VMG needs App Wind Speed, App Wind Dir, Speed
TRUE WIND SPEED needs App Wind Speed, App Wind Dir, Speed
TRUE WIND DIR needs App Wind Speed, App Wind Dir, Speed
ETA/TTG needs VMG-WP and DTW.

The way I'm timing transmissions is ignoring the first request from the display (it's what the stock hull transmitter did). Sending a data packet 500us after the second request which gets the data displayed and a 0x0b message from the display that I'm currently ignoring. Then changing the send wait time from 500us to 13ms. If I don't adjust the wait time the display doesn't see my packet. The stock hull transmitter only waited 2ms to send it's data.

Working theory is since I'm not replying correctly to the 0x0b packet the display gives my device the last transmitting slot. It still accepts data if I change the device's ID or type as long as I transmit during my assigned slot which is around 12ms to 14ms after the request. It's possible that skipping the first packet is part of how devices order themselves during network startup. NMEA converter answers the first packet and gets it's slot, hull transmitters the second, then probably wind vane on the 3rd.

I'm going to look into the 0x0b/0x0a interaction tomorrow. I'd like to get my esp to register as a nmea converter in the options->health menu. See if it bumps up my slot.

We have them all for the dual display !
I moved my transmission window and you are right : my packets are taken into account now. I don't need to fill device id or anything else than the network ID and the message ID. I have to clean-up my code and to add a proper way to transmit my messages to the network. I will use a timer interrupt, triggered by the reception of main display Sync Word. This way I will be able to reliably start my transmission at the right location.
This opens a wide spectrum of very interesting applications to us.

 

[tty]

Well today is a sad day. My dual display fell off the nav table a whole 2 feet and won't power on now. If I unplug the battery and plug it back in the display comes on with micronet rst but the power button does nothing. I've looked it over and can't find anything obviously broken on the back side. Having the screen blocking the front side of the PCB rules out backwards engineering. I'll play with it a bit more but it's probably headed back to the dumpster. Raymarine durability. RIP

Edit: Never mind, got it working stealing components from the hull transmitter. Three of the four buttons work. Good enough. This thing is really turning into a time sink.

 

[Rodemfr]

Well today is a sad day. My dual display fell off the nav table a whole 2 feet and won't power on now. If I unplug the battery and plug it back in the display comes on with micronet rst but the power button does nothing. I've looked it over and can't find anything obviously broken on the back side. Having the screen blocking the front side of the PCB rules out backwards engineering. I'll play with it a bit more but it's probably headed back to the dumpster. Raymarine durability. RIP

Edit: Never mind, got it working stealing components from the hull transmitter. Three of the four buttons work. Good enough. This thing is really turning into a time sink.

Good to hear that you managed to recover most of your display.
On my side, I'm now able to transmit position/sog/cog/time/date from a UBLOX Neo M8N GPS to my display. This is really a major step forward but I still have issues to solve. The configuration of my CC1101 is probably bad since transmiting power is very low. Display cannot decode it at more than 50cm (1.5 ft). It's time to write my own driver of CC1101, dedicated to Micronet.

 

[tty]

Thanks. I can show you the settings the CC1000 used. Those along with its datasheet might help you. It has two frequency registers you can switch between for RX/TX. They are set with frequency 'words' that use a few other settings and some voodoo math on page 23 to get a frequency out of.

The TX freq_word for 868mhz band is 5791744(869.9904mhz?). I don't know the TX word because the hull transmitter doesn't broadcast until it sees a display and my system uses 915mhz band.

The 915mhz band freq_words are 8134656(916.0704Mhz) for RX and 6103040(915.88845Mhz) for TX. My calculated frequencies maybe off a bit because not all the values in the formula are known to me.

Reference divider is set to 8 for RX and 6 for TX.

The frequency separation word is 427 which is 64050 Hz with a reference divider of 6 (TX) or 48037.5 Hz with a reference divider of 8 (RX). The changing frequency separation might be a design oversite or maybe the radio doesn't care about the reference divider when receiving. Not sure why they set it up the way but that's what I mimic.

I get over 100ft range in open air but anything in between drastically cuts the range which is inline with the stock hull transmitter and display.

 

[Rodemfr]

Thanks. I can show you the settings the CC1000 used. Those along with its datasheet might help you. It has two frequency registers you can switch between for RX/TX. They are set with frequency 'words' that use a few other settings and some voodoo math on page 23 to get a frequency out of.

The TX freq_word for 868mhz band is 5791744(869.9904mhz?). I don't know the TX word because the hull transmitter doesn't broadcast until it sees a display and my system uses 915mhz band.

The 915mhz band freq_words are 8134656(916.0704Mhz) for RX and 6103040(915.88845Mhz) for TX. My calculated frequencies maybe off a bit because not all the values in the formula are known to me.

Reference divider is set to 8 for RX and 6 for TX.

The frequency separation word is 427 which is 64050 Hz with a reference divider of 6 (TX) or 48037.5 Hz with a reference divider of 8 (RX). The changing frequency separation might be a design oversite or maybe the radio doesn't care about the reference divider when receiving. Not sure why they set it up the way but that's what I mimic.

I get over 100ft range in open air but anything in between drastically cuts the range which is inline with the stock hull transmitter and display.

Thanks for CC1100 settings. I will check but I suspect to have a faulty board. It emits at the same low power level, with or without the antenna. I can change Tx power by changing the settings but the level is ridiculously low. Something must be wrong with the connections. I'm not equipped to analyze/repair this. I think I will order another board of another brand, it's cheap...

Anyway, I made an interresting discovery : I found the meaning of the "unknown byte" in the "request Data" message (0x01) :

|83.03.77.37|83|03.77.37|01|09|00|72|28.28|83.03.77.37|1C|02.03.90.87|0C|01.0B.C0.22|26|81.03.70.82|0E|83.03.77.37|0E|00.00|52|
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|....DID1...|PL|....DID2...|PL|....DID3...|PL|....DID4...|PL|....DID5...|PL|.???.|CS|
|.............MESSAGE.HEADER..............|.................................REQUESTED.DEVICES.................................|

The value of "PL" is the maximum number of bytes expected in the payload of the advertised device (without header, sync word or preamble). These value have probably been provided to main display by each devices during pairing sequence.
I also noticed that devices answer in the exact same order than the one of the "Request Data" message and that if a device emits twice, it is listed twice in this message. Said in another way, this message gives the temporal description of the full data exchange on the frequency. By decoding it on the fly, you can know in which window you can emit. In our case, we have to calculate the total size of all messages (including guard time, preamble and sync word) and we will know where to transmit our additionnal data to the display, even if a new device is added later to the network.

 

[Rodemfr]

It starts to look nice !

 

[tty]

Very interesting. I've looked at my own data and your analysis on talk order looks spot on. This isn't a data request packet as much as a network ordering packet. I'm not sold on PL though. For me PL is 2 more than packet size. I'm fairly sure the devices don't blindly set tx times off this packet. There's instances when two devices will talk back and forth ignoring the order. For example when a new device is powered on the 0x0a/0b packet exchange or an alarm's 0x06/07's. There's a window 3.5 ms long 10ms after a data packet is sent for (assuming) the master to query the device that sent the data so you still have to monitor the entire conversation to know when it's your turn to speak.

Here's a normal sequence. 10ms after the hull transmitter sends it's packet it listens 3.5ms for follow ups.



Here's an alarm crosstalk.

10ms after the data packet the master sends a 0x06 packet. hull transmitter replies with a 0x07, master replies with a 0x07 then the hull transmitter listens for 3.5ms, doesn't hear a packet and goes back to sleep.

ps. I have the same toadstool speaker. lol.

 

[Rodemfr]

All my observations were made in a stable state (i.e. no alarm or 0xa/0xb). So it may very well be that my understanding of the communication is a bit trivial. Like you I have seen stranges situations in which the "Request Data" timing seemed not to be respected. I ignored them so far...

This 10ms hole is strange. The only situation in which I observed such a silence was when I put my wind transducer out of range. It's slot was empty but still preserved by other devices.

On my side, I looked to the effect of changing hull transmitter configuration by connecting/disconnecting the sounder. The size of the packets sent by HT changes accordingly. I followed the effect on the "Rx Window" on which I insert my GPS data, and I found that it was moving accordingly to the packet size change. With a huge statistical analysis of 2 samples, I deducted this formula to start transmission of my pirate packet :

time_delay = (n - 1) * 6000us + 104us *nbBytes

where:

- time_delay is the time to wait from the end of the "Request Data" packet from the main display.
- n the number of devices listed in the "Request Data" packet
- nbBytes : the total number of payload bytes (excluding header or preamble bytes)
- 104us is the time to transmit one byte at 76800 baud

This formula works for my two possible configurations but is likely wrong. I expect it to fail as soon as I will add a new device in the network.

I suspect that the Tx slot I'm using after all the other device is there for unusual situation like alarms or other various situation change. I think transmitting there will affect the system in one way or one another. What I need now, is to understand the pairing algorithm.
I will stop investigating the protocol. I now want to build a proper case for this small system. I want to navigate with it when my boat will go at sea on April.
When I will come back for investigations, I will have a look to the pairing sequence.

PS : the toadstool speaker is very good ... for its price !

 

[tty]

Ok, how about if this 'cross talk' window is at the end of the last device in the order. The master sends an order packet, everything answers in order, after the last data packet everyone listens for any special packets from the master then go to sleep. It's always at 10ms for me because I only had the two devices. Do you know when 0x0a/0x0b interactions happen on your network?

 

[Rodemfr]

This is the activity diagram of my network at startup. Let's number these activity burst from 1 (left) to 7 (right). here is what happens :

First burst, master request data, as usual :
83 03 77 37 81 03 70 82 01 09 00 B4 28 28 81 03 70 82 1C 02 03 90 87 0C 83 03 77 37 00 81 03 70 82 0E 01 0B C0 22 26 00 00 86 (42,-51)
The first device which should answer to the master does not respond (yet). This is why we have a "hole". This is the wind transducer (0x02039087). It will answer, but later (outside this graphic).

Then we have the second burst which is my dual display who answers to himself :
83 03 77 37 81 03 70 82 02 09 00 B5 0C 0C (14,-51)
Note that his slot allow 0x0e bytes but since it has nothing to provide, it just sends a packet with no paylod (0x0c length). A sort of acknowledge.

Then the third burst is my hull transmitter answer :
83 03 77 37 01 0B C0 22 02 01 09 2E 18 18 04 04 05 13 89 A9 04 1B 05 00 00 24 (26,-74)
Nothing special here.

And this is all for the "requested" communication. Note that, in the request from the master, there is a listed device 0x 83037737 with an allowed payload of zero. This is probably just to tell everybody which devices are belonging to the network, but in this case, no space is reserved for this device to talk on the frequency, even if a zero payload packet can take quite some time to transmit with its header and pre-amble. So a payload of zero really means that the device has no slot to talk.

Now comes the interesting part. Starting after the communication scheme described in the "Request Data" command, exactly at the position I use to transmit my GNSS data, the master initiate the 0x0a/0x0b communication. Those are the 4 remaining bursts :
83 03 77 37 81 03 70 82 0A 09 00 BD 0C 0C (14,-52)
83 03 77 37 01 0B C0 22 0B 01 09 37 0E 0E 00 00 (16,-74)
83 03 77 37 81 03 70 82 0B 09 00 BE 0E 0E 10 10 (16,-53)
83 03 77 37 83 03 77 37 0B 09 06 82 0E 0E 10 10 (16,-82)

This extra communication starts ~11,7 ms after the end of the previous packet. This might correspond to your 10ms delay.

 

[Rodemfr]

If I consider that the last "extra" Tx slot is shifted compared to the 4 previous ones, all my calculations are behaving better.
I do my measurements only on the slot listed in the "Request data" sequence and I find, on average, the following structure for each slot :

- 1770us of preamble + sync word
- 1458us of header
- 104us * payload_length of payload (104us = 1 byte at 76800baud)
- 2000us of guard time before next slot

Considering this, I find that the "extra" slot is ... just 10ms after the last slot. This is exactly the time you observe in your measurements.

 

[Rodemfr]

A question for you TTY : have you seen in your open device any button or "thing" that could possibly trigger a real factory reset ?
I finally started to investigate the auto network sequence to be able to add my device and to get an "official" transmission slot. However I'm facing an issue.
While it is relatively easy to understand what the master is doing, all my slave devices are already paired and do not engage the auto network sequence.
In the manual, the only way to remove a device from a network is to pair it to another network. The "Factory reset" option in the menu resets all but the attached network.