Raymarine's Micronet

[tty]

Very interesting. Your Friday post has another device running the network.

|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|

DT=0x83 which would mean the wind vane is sending out network master packets. Maybe it uses a different ID when it is running the show?

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.

Interesting that your display gives itself a slot then answers itself. That's new to me.

This is what my network's master packet looks like.

 01 0A 8B 60 81 03 61 7C 01 09 00 61 19 19 81 03 61 7C 0D 01 0B 8B 60 1A 00 00 7F 13
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|....DID1...|PL|....DID2...|PL|....DID3...|PL|....DID4...|PL|....DID5...|PL|.???.|CS|

Next message I see is a tx from the hull transmitter.

 01 0A 8B 60 01 0B 8B 60 02 01 09 F9 18 18 04 04 05 13 89 A9 04 1B 05 00 00 24 
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|

What's interesting is that the hull transmitter doesn't even listen to the display's slot. Guess it doesn't care.

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.

There's no marked hardware factory reset inside the devices. Service would probably use the 8 pin jtag in the battery compartments. I did look at pairing when I first started playing around with these things. It wasn't that complex. Long preamble, some packets and proximity. Devices had to be really close. I didn't dive into why but the display could be setting papow to 0 for this effect and/or measuring RSSI on pin 28 of the CC1000 as it is connected to the MCU and configured for analog signal strength.

I was headed the same way trying to get a proper slot when my display broke. Right now I don't have a right button so can't work the options menu. Replacements come this week. The part I stole off the hull transmitter is backordered till may so it'll be a long time, if ever, it'll ever talk again. So far everything has been very straight forward. Lets hope pairing will be too.

 

[Rodemfr]

Very interesting. Your Friday post has another device running the network.

I have two displays : Dual display and analog wind display. The one you power-up the first becomes the master, wake-up the others and sends the 0x01 command every seconds.

I'm very frustrated not to be able to record a complete auto network sequence. I feel we are very close to have it, but I need another TackTick network, which I don't have ...

 

[tty]

You have an analog wind display and a dual display? Then you have everything you need. Reset whichever is not the master of your network and pair it to any of your other devices making it master of a new network. As long as the first network isn't active you can pair already paired device to a new network. Any display can become a master.

 

[Rodemfr]

Unfortunately it does not work. Both display having been paired together, they always reuse the same network ID when starting a new auto network sequence, even when isolated. All devices already belonging to it simply ignore the auto network request.
There is however a strange page in the option menu : "Master ON/OFF". It is not documented, and I did not find what could be its effect.

 

[tty]

Small observation. While waiting for parts I started programming the canbus/nmea2000 part of my converter. During so I left it on sending out a test data packet. Yesterday I noticed the network master packet changed. The display dropped the hull transmitter from the list even though I was sending data using the hull transmitter's ID. It still reads my packets and displays my data. Only change is it doesn't try to talk to the hull transmitter anymore. No more 0x0a/0x06/0x07's. This was beneficial for me as it turns the display into a dumb display. So there is a mechanism to drop 'dead' devices from the network. My money is on the 0x0a/0x0b interaction or possibly not using the right slot coupled with an error counter.

 

[Rodemfr]

Very interesting, I will shield my hull transmitter for a while and see if it is removed from the list.
In parallel, I'm creating a dedicated SW on my Teensy to mimic a master with a different network id. I saw that when switching to Auto Network, Master is sending the "Request data" 0x01 command but with destination byte set to 0xD instead of 0x0 (or the byte I suppose to be some sort of destination) . I will send this and see what slaves are responding when the netowrk ID is not the one they are attached to.

 

[tty]

I moved my left button to the right button spot so I could get into the settings menu. Been working on decoding 0x06 command messages. Command messages are acknowledged by devices with a 0x07 packet. I can remote change all these settings and even turn the backlight on/off.

0x06 Command packets.

0xE5 Display backlight command. (Follows the settings command format with only 1 setting byte for intensity)
Backlight Off: 01 0A 8B 60 81 03 61 7C 06 09 00 66 10 10 E5 00 10 F5
Backlight  L1: 01 0A 8B 60 81 03 61 7C 06 09 00 66 10 10 E5 01 0D F3
Backlight  L2: 01 0A 8B 60 81 03 61 7C 06 09 00 66 10 10 E5 02 0E F5
Backlight  L3: 01 0A 8B 60 81 03 61 7C 06 09 00 66 10 10 E5 03 0F F7

0xFF Settings command.
FF 01 01 00 24 25
CW RG SS SS CT CS
CW = Command word.
RG = Registry.
SS = Settings.
CT = Counter. Every time a setting is changed this increments. Probably for synchronization. Doesn't seem to matter on my network. Maybe it would with multiple devices.
CS = Checksum.

0xFF Reg 0x00 Speed adj. +/- 200%
  speed +1%: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 00 01 33 6D A0
  speed +2%: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 00 01 34 6E A2
speed +200%: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 00 01 FA 6F 69

0xFF Reg 0x01 General Settings.
Default settings (all zeros) are: Depth in feet, Speed in knots, Wind in knots, Log units in nm. It is bit based. Not fully mapped.
      Default: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 00 24 25 bits: 0000 0001 0000 00001 0000 0000
    Speed mph: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 01 30 32 bits: 0000 0001 0000 00001 0000 0001
    Speed kph: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 02 2F 32 bits: 0000 0001 0000 00001 0000 0010
 Log units sm: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 04 26 2B bits: 0000 0001 0000 00001 0000 0100
 Log units  m: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 08 25 2E bits: 0000 0001 0000 00001 0000 1000
Depth  meters: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 10 13 24 bits: 0000 0001 0000 00001 0001 0000
Depth fathoms: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 20 15 36 bits: 0000 0001 0000 00001 0010 0000
  Wind meters: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 01 01 40 1F 60 bits: 0000 0001 0000 00001 0100 0000

0xFF Reg 0x02 Sea temp adj. +/- 10c
 temp .5c: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 02 01 01 6B 70
 temp +1c: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 02 01 02 6C 70
temp +10c: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 02 01 14 6E 84

0xFF Reg 0x0B More General Settings/Some alarm settings. Bit based. Not fully mapped.
       Temp f: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 0B 01 01 2D 39 bits: 0000 1011 0000 00001 0000 0001 (default is c)
 WP Arv Alarm: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 0B 01 10 5B 76 bits: 0000 1011 0000 00001 0001 0000
    Alarm XTE: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 0B 01 20 67 92 bits: 0000 1011 0000 00001 0010 0000
Spd frmt 0.01: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 0B 01 40 38 83 bits: 0000 1011 0000 00001 0100 0000 (default is 0.1)

0xFF Reg 0x11 Depth alarm deep.
depth alarm deep 1ft: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 11 01 01 57 69
depth alarm deep 2ft: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 11 01 02 5A 6D

0xFF Reg 0x12 Depth alarm shallow.
Depth alarm shallow .5ft: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 12 01 05 54 6B
 Depth alarm shallow 1ft: 01 0A 8B 60 81 03 61 7C 06 09 00 66 12 12 FF 12 01 0A 59 75

0xFF Reg 0x13 CRSE Alarm.
 CRSE Alarm 1 degree: 01 0A 8B 60 81 03 61 7C 06 09 00 66 13 13 FF 13 02 01 00 5D 72
CRSE Alarm 2 degrees: 01 0A 8B 60 81 03 61 7C 06 09 00 66 13 13 FF 13 02 02 00 5E 74

Edit: Figured out how to get something added to the master packet's list. 0x03 packet. No pairing required lol.

0x03 packet. Data is an unknown 0x00 byte followed by the window size you want then a checksum. Repeating this packet with a different window size does not change your window size.
Recieved 22 bytes. 01 0A 8B 60 81 03 61 7C 01 09 00 61 14 14 81 03 61 7C 08 00 00 69
Sending 17 bytes.  01 0A 8B 60 01 0B 8B 60 03 01 09 FA 0F 0F 00 1A 1A
Recieved 27 bytes. 01 0A 8B 60 81 03 61 7C 01 09 00 61 19 19 81 03 61 7C 0D 01 0B 8B 60 1A 00 00 7F
Sending 17 bytes.  01 0A 8B 60 01 0C 8B 60 03 01 09 FB 0F 0F 00 1A 1A
Recieved 32 bytes. 01 0A 8B 60 81 03 61 7C 01 09 00 61 1E 1E 81 03 61 7C 12 01 0B 8B 60 1A 01 0C 8B 60 1A 00 00 96
Sending 17 bytes.  01 0A 8B 60 01 0D 8B 60 03 01 09 FC 0F 0F 00 20 20
Recieved 37 bytes. 01 0A 8B 60 81 03 61 7C 01 09 00 61 23 23 81 03 61 7C 17 01 0B 8B 60 1A 01 0C 8B 60 1A 01 0D 8B 60 20 00 00 B4

 

[Rodemfr]

Edit: Figured out how to get something added to the master packet's list. 0x03 packet. No pairing required lol.

It works, excellent !!! You saved me a long and painful reverse engineering of the pairing sequence...

 

[Rodemfr]

I cannot trigger the complete auto network sequence with my weak Rf transmitter (I found why it is weak : SmartRC driver is buggy and calculates wrong PLL coefficients and I'm off the requested frequency). However, with your finding of 0x03 command, I think we can easily guess the procedure :

There is a first 15s seconds sequence called "wait" during which the master sends the 0x01 command but with source set to 0x0f instead of 0x09. During this sequence, all the time between two 0x01 commands (~1s) is filled with the preamble pattern transmitted at full power. This is the same pattern which is sent during the 5-6s at power-up of the system. This is very likely to wake-up sleeping devices which are using Wake-On-Radio feature of CC1000/CC1101.

Then comes the second phase of auto network (~50s) , called "Wait". In this phase, long preambles to wake-up the devices are not more transmitted. The master starts sending the same command than in the previous phase (0x01), but with destination set to 0x0d instead of 0x0f.
In my case, nothing more happens there because my transmitting signal is too weak, the slave device does not see me in the 30cm/1ft radius. But it is very likely that the 0x03 command is sent by the slave to insert its device ID into the network.

 

[Rodemfr]

By the way, two additionnal commands :

Master (0x83037737), request other displays to reset ->
83 03 77 37 83 03 77 37 06 09 09 80 12 12 FA 4F 46 46 26 FB
Master (0x83037737), request all devices to shutdown ->
83 03 77 37 83 03 77 37 06 09 00 77 12 12 FA 4F 46 46 10 E5

Note that this is the same command than for calibration parameters but with 0xfa instead of 0xff as "sub-command" byte.
Also note that 0x4f 0x46 0x46 is 'OFF' in ASCII

 

[tty]

This is very likely to wake-up sleeping devices which are using Wake-On-Radio feature of CC1000/CC1101.

CC1000 doesn't have that feature. Instead they just wake up once a second and listen for a preamble to lock the average filter to. Pairing is a bit different depending on master on/off. The packets sent out are standard network master/request data packets but with the destination byte (this might actually be a timing byte) changed.

Network master on/off seems to turn on a lot of the protocol checks. You get 5 tries to do things then are removed from the list. After 0x03 a network master sends out 3 big settings packets (FF 00 0D 32 00 01 DD 00 00 00 00 00 00 00 00 00 01 1D , FF 0D 0D 00 0A 05 00 00 00 00 00 00 00 00 00 00 02 2A, FF 1A 0A 00 5A B4 00 00 00 00 00 00 00 03 34 ) and a 4th smaller unknown packet (FE 24 04 26). If you don't 07 these messages you will get booted. If you transmit out of slot you will get booted. The timing seems tighter but I can't really verify it. Devices can still exceed their allotted windows as I saw the master do it itself.

I'm going to work on a precision send function so I can be a good micronet device and hopefully stop getting booted out. ?

Master (0x83037737), request other displays to reset ->
83 03 77 37 83 03 77 37 06 09 09 80 12 12 FA 4F 46 46 26 FB
Master (0x83037737), request all devices to shutdown ->
83 03 77 37 83 03 77 37 06 09 00 77 12 12 FA 4F 46 46 10 E5

And the last bit is 01 if it's just one device turning off. ie. FA 4F 46 46 01 D6

I'm beginning to think this is a round robin network that stops when no one talks but only having the one device can't really verify.

 

[Rodemfr]

We start to have a really good picture of the protocol, that's great !

On my side, I got a new command. My hull transmitter sends packet of different sizes whether the sounder in actually connected or not. Logging the power-up sequence with and without the probe allowed me to see the command sent to request a payload size change to the master :

|83 03 77 37|01 0B C0 22|05|01|09|31|0E 0E|3D|3D|
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|NS|CS|

NS -> New size

The next request from the master will have the requested size. Note that this command is only understood when sent in the "extra" slot, not in the "synchronous" slot.

Currently, my SW parses each 0x01 message and checks if my device is listed. If not I request insertion with 0x03 command. This way, I don't care beeing booted out. It works well but I would prefer to properly handle the 0x0a/0x0b handshake. The question is : what is the meaning of this one byte value in the 0x0b message payload ? My Analog wind display answer 0x10, my hull transmitter 0x00, my dual display (the master) 0x90, and My wind transducer ... does not answer !?

 

[tty]

The question is : what is the meaning of this one byte value in the 0x0b message payload ? My Analog wind display answer 0x10, my hull transmitter 0x00, my dual display (the master) 0x90, and My wind transducer ... does not answer !?

Great question we might never know. 0a/0b's don't seem to be sent at any particular time or for any particular reason and don't seem to have any particular effect. I have logs where they were never sent, logs where they were sent multiple times and logs where my hull transmitter answered differently (0B 01 08 and 0B 01 09). Whatever they are my display doesn't bother sending them to me anymore.

 

[tty]

I've been coding a network master device so I can send the display some of these unknown packets to see how it responses. If you want to change one of your displays to another network you just have to send out network master packets for another network and initiate an 'auto network' on the display. After the timers tick down the display will adopt the new network's id. No special packet handshake required.

My display uses a 03 09 packet to request a time slot. I believe the value in the master packet proceeding a device is window size in 10th of ms. I coded a test where I incremented that byte by 10 every second. My display responded by moving it's TX window accordingly.

byte mp[62] = {0x01, 0x0A, 0x8B, 0x60, 0x01, 0x0B, 0x8B, 0x60, 0x01, 0x09, 0x00, 0xF7, 0x14, 0x14, 
                 0x81, 0x03, 0x61, 0x7C, xxy,
                 0x00, 0x00, 0x00};

0019.00018312: Received 17 bytes: 01 0A 8B 60 81 03 61 7D 03 09 06 6A 0F 0F 00 00 00 
0019.00018789: This was received 8369 us after our send. 19th byte was 00 <- xxy is the 19th byte
0025.00019295: Received 17 bytes: 01 0A 8B 60 81 03 61 7D 03 09 06 6A 0F 0F 00 00 00 
0025.00019627: This was received 9361 us after our send. 19th byte was 0A
...
0131.00044274: Received 17 bytes: 01 0A 8B 60 81 03 61 7D 03 09 09 6D 0F 0F 00 00 00 
0131.00044582: This was received 34381 us after our send. 19th byte was FA

The display is replying with 03 09 packets requesting a 0 ms time slot. It is sent during the end window that I've been abusing to display data. That spot is actually for devices not listed in the master packet to talk to the master and get a timeslot. In the above example the new device window is currently at 8000ms after the master packet but it depends on the number of devices listed as every device gets a ~5-6 ms crosstalk window in addition to their data windows.

If I give my display a 0 length window it will stop sending 03 09's and won't reply to the master packet. If I give it a window of say 1 ms it will reply to every master packet with a 02 09. I believe it requests a 0 sized window to get a crosstalk slot which it uses to squawk settings changes.

The earliest window I've seen is 1 ms after the master packet.

0013.00011285: Received 14 bytes: 01 0A 8B 60 81 03 61 7E 02 09 09 6D 0C 0C 
0013.00011541: This was received 1031 us after our send. 19th byte was 00

If a device is turned on and it sees its id already listed in the master packet list but not at the slot or size it remembers instead of taking the listed slot it will increment it's id by one and request a new slot. Devices will only accept their slot if it's added to the end of the list.

byte mp1[62] = {0x01, 0x0A, 0x8B, 0x60, 0x01, 0x0B, 0x8B, 0x60, 0x01, 0x09, 0x00, 0xF7, 0x14, 0x14, 
                        0x81, 0x03, 0x61, *0x7E*, 0x60, 
                        0x00, 0x00, 0x00};

0018.00028311: Received 20 bytes: 01 0A 8B 60 81 03 61 *7E* 06 09 07 6F 12 12 FA 4F 46 46 01 D6 <- shutdown the display and changed it's size.
0026.00018324: Received 17 bytes: 01 0A 8B 60 81 03 61 *7F* 03 09 08 6E 0F 0F 00 00 00 <- on restarting the display incremented its id and requested a new slot.

A device will only send an 03 09 request packet once every few seconds. The range is around 3 to 8 seconds. Seems random. Probably is since the new device window is a crapshoot and if every device tried to talk every time during it nothing would get added.

Here is how my duel display answers an 0x0a packet.

01 0A 8B 60 81 03 61 81 *0B 09 09* 79 0E 0E *10* 10

So a hull transmitter answers 0B 01 with 0x00 payload and a display 0B 09 with 0x10 payload. That matches what you've seen. Maybe the 0x0a/0x0b is a device type message.

 

[Rodemfr]

Hi,

I'm back from two weeks of coastal navigation during which I tested the system in real conditions : It works fine !
I connected the Micronet<->NMEA bridge to the uBlox GPS, to OpenCPN/qtVlm and to my Micronet devices and I was able :

• To use all GPS and Micronet data into OpenCPN and qtVlm.
• To see GPS data on my Micronet display (COG, SOG, position, date and time)
• To display OpenCPN and qtVlm's navigation data onto my micronet display (DTW, BTW, and XTE)

During all my testing I only lost GPS data twice for one or two minutes (for several days of usage), I don't know why : GPS lock lost ? Micronet transmission slot gone in master's device list ? Missed transmission window ?

Next step : use Arduino NANO BLE instead of Teensy 3.5 and use its internal magnetometer to add magnetic compass to the system.

 

[tty]

Great to hear. I picked up a cc1101 and was playing with it. The range/power is horrible compared to a cc1000. Even with the power turned up to max it doesn't get 1/10th the distance as a cc1000 (measured with a RTLSDR dongle). Did you ever get any better range out of your setup?

The NANO BLE is an interesting choice. Why not an ESP32 with a LSM303 or HMC5883L? The NANO seems expensive for what you get.

 

[Rodemfr]

Great to hear. I picked up a cc1101 and was playing with it. The range/power is horrible compared to a cc1000. Even with the power turned up to max it doesn't get 1/10th the distance as a cc1000 (measured with a RTLSDR dongle). Did you ever get any better range out of your setup?

The NANO BLE is an interesting choice. Why not an ESP32 with a LSM303 or HMC5883L? The NANO seems expensive for what you get.

I managed to get a correct range with the cc1101 when I started transmitting and discovered that the frequency I was configuring was not not the central frequency of the FSK modulation but the lower one (or higher, I don't remember). I also saw that the distance between frequencies was not 32khz but something like 34 or 36. All values are approximatives because measured with with my RTL-SDR dongle, which I do not really trust. So I changed my config and quality was suddently better. This is however not as good as my TackTick devices.

I received the NANO BLE but the choice is not as good as I was hoping : it has no EEPROM to save calibration data and no EEPROM emulation. I did not use ESP32 because I don't know well this familly. I will check. The magnetic compass is however working fine and easy to use...

I also started writing a Linux Kernel Module to interface CC1101. The idea is to create a char device which would directly output a NMEA stream created from Micronet data and to accept another NMEA stream as input which would be converted to Micronet packets. A Raspberry Pi could then become a powerful device to interface with a Micronet network : Access to bluetooth and WiFi, could be used directly on OpenPlotter systems, etc.
It will not come soon however : coding in kernel space is painful, and I never did it before...

 

[Booster]

First many thanks for the effort you spent.
I have the combination with triducer, hull transmitter and mn 100-2 display in my boat.
I tried to follow your findings by catching the signal with my RTL-SDR stick. Converting to pulse view and made a UART decoding wit 76,8k baud rate and 8N1:

I found the preamble with 0x55 but no sync word 0x5599. I think something is wrong with my setup because I have the frame errors to see in the UART warnings row. Perhaps you can give me few hints to improve my setup.

 

[tty]

Your issue is the data stream is not 8n1. There's no start or stop bits. It's just an asynchronous bit stream. The preamble is there so the cc1000's can tune their averaging filter for the strength of the sender and sync baud timing. The sync word is there to align the decoder to bytes.

Here is your 0x99 (b10011001). Part of it is getting cut off by the decoder thinking it's a start/stop bit(s).


Good luck!

 

[Booster]

Thanks for the response.
Yes, now I see it is a simple bit stream. Do you have an idea how I can decode this to byte sequence with pulseview starting from sync word. The UART decoder can't configured without start and stop bit and with OOK-NRZ I lost the byte structure.
I made different attempts with rtl_433 file read in like:
rtl_433 -r g001_869.84M_1000k.cu8 -R 0 -X "n=micronet,m=FSK_PCM,s=13,l=13,r=2048,preamble={16}5599"
but w/o success.
Sorry to be a bit OT.