TernVI
Well-known member
It may (or may not!) be of interest that you can get compatible CC1101 chips on a breakout PCB from ebay?
E07-868MS10 CC1101 868MHz SPI 10dBm 1000m Wireless RF Transceiver 1.8-3.6V | eBay
Bit pricey, over four quid!
Raymarine's Micronet
- Thread starter Gixer
- Start date
E07-868MS10 CC1101 868MHz SPI 10dBm 1000m Wireless RF Transceiver 1.8-3.6V | eBay
Bit pricey, over four quid!
Spirit (of Glenans)
Well-known member
Forgive me if I'm mistaken, but isn't Micronet just N2K/Devicenet with smaller connectors?
Daverw
Well-known member
Micronet is Raymarine’s Tacktick wireless interface network
tty
Member
Morning everyone. I've come across some micronet kit (t100 without transducers) and, like you, loved its potential but found how useless it is without the t122 unit. I'm debating on trying to backwards engineer the protocol. Has anyone made progress on it?
tty
Member
I soldered a logic analyzer in between the CC1000 and MCU in the hull transmitter unit so I could snoop the protocol. I have the CC1000's register settings so talking with the devices isn't a problem but the protocol is more complex than thought. Whenever a device connects there's a bidirectional handshake period and settings exchange that lasts around 6 seconds. The transmitter won't send out and the receiver won't display data without this handshake. I'm guessing it's some kind of pairing so that systems on different boats won't commingle. I'll have to write an analyzer to help break down the protocol but free time is limited. If someone here wants to help/collab let me know.
Rodemfr
Member
Hi all,
Thanks to all the above information I was able to configure a CC1101 board (like this one) to capture Micronet packets from my tacktick devices. I use a Teensy 3.5 board (Arduino compatible) to execute the decoding software.
After some work I can complete the description of the protocol :
*** Modulation :
I have a carrier frequency of 869.784MHz instead of 869.845MHz but I'm not sure it is relevant, it might be measurement errors. All the rest is the same than in nrcoyle post.
*** Protocol :
Here I found some interesting new information. The sync word is 0x9983, not 0xb320. I don't really explain such a difference since all micronet devices must use the same word for them to be able to discuss together.
Using this sync word, the wind message becomes much easier to understand and values are suddently evident to decode.
Comparing ncoyle message to mine, I was able to better understand the message structure :
09 ca 2e 02 0a ca 2e 02 01 09 13 18 18 04 05 05 00 00 0e 04 06 05 00 32 41 d6 b9 6b 6f a5 d6 7a 66 78
03 77 37 02 03 90 87 02 01 07 5A 18 18 04 05 05 00 00 0E 04 06 05 00 57 66 25 C7 06 92 12
NID |DT| DID | MID |?1|C?| LEN | FD1 | AWS |C1| FD2 | AWA |C2|
COMMON PART | SPECIFIC PART |
The first message is ncoyle wind message shifted by 3 bits left to match 0x9983 sync word.
The second message comes from my wind transducer.
The third line is my understanding of the values.
We see that the two structures match well up to the C2 byte. I also compared to the other messages of my network (Hull Transmitter, Analog wind display, dual display) and come to the following conclusions :
All fields from NID to LEN are common to all messages, regardless of the type of device. All the fields after LEN are specific to the type of message.
*** Common part ***
NID = Micronet Network ID. At least, it really looks like. The small value of the first byte let me think that it could have a special meaning.
DT = Device Type
2 Wind Transducer
83 Analog Wind Display (bit 7 seems to mean that the device is a display)
81 Dual Display
1 Hull Transmitter
DID = Device ID ? Seems to be unique to each device. Unsure if it has any other meaning.
MID = Message ID - Describe the message and tells the receiver how to decode the specific part of the message.
0x0201 Wind measurements - I bet that 0x02 means "wind"
C? = Looks like a checksum but I did not find the way to calculate it. I observed that ifa single byte increase by one in the previous bytes, this one also increases by one.
LEN = length-1 of the packet in byte. Value duplicated on the two bytes, probably for robustness. It allows to now how many byte we have in the specific part of the message
*** 0x0201 specific part ***
FD1 = This is probably a field descriptor which tells what is the following data (AWS in the example).
AWS = Wind speed in knots*10 coded as 16-bit integer. Just devide by 10 to get speed in knots.
C1 = Field checksum. Addition of the five previous bytes (4 + 5 +5 + 0 + 0 = 0xe)
FD2 = Same as FD1 except for a 5 becoming a 6, probably means AWA instead of AWS
AWA = AWA angle in degrees, coded with a signed 16-bit interger.
C12 = Field checksum. Addition of the five previous bytes (4 + 6 + 5 + 0 + 57 = 0x66)
There is a lot more to discover and will probably come back later with new messages and fields.
For those who are interested in the code which initializes the CC1101, I can provide it by mail.
Best regard.
Thanks to all the above information I was able to configure a CC1101 board (like this one) to capture Micronet packets from my tacktick devices. I use a Teensy 3.5 board (Arduino compatible) to execute the decoding software.
After some work I can complete the description of the protocol :
*** Modulation :
I have a carrier frequency of 869.784MHz instead of 869.845MHz but I'm not sure it is relevant, it might be measurement errors. All the rest is the same than in nrcoyle post.
*** Protocol :
Here I found some interesting new information. The sync word is 0x9983, not 0xb320. I don't really explain such a difference since all micronet devices must use the same word for them to be able to discuss together.
Using this sync word, the wind message becomes much easier to understand and values are suddently evident to decode.
Comparing ncoyle message to mine, I was able to better understand the message structure :
09 ca 2e 02 0a ca 2e 02 01 09 13 18 18 04 05 05 00 00 0e 04 06 05 00 32 41 d6 b9 6b 6f a5 d6 7a 66 78
03 77 37 02 03 90 87 02 01 07 5A 18 18 04 05 05 00 00 0E 04 06 05 00 57 66 25 C7 06 92 12
NID |DT| DID | MID |?1|C?| LEN | FD1 | AWS |C1| FD2 | AWA |C2|
COMMON PART | SPECIFIC PART |
The first message is ncoyle wind message shifted by 3 bits left to match 0x9983 sync word.
The second message comes from my wind transducer.
The third line is my understanding of the values.
We see that the two structures match well up to the C2 byte. I also compared to the other messages of my network (Hull Transmitter, Analog wind display, dual display) and come to the following conclusions :
All fields from NID to LEN are common to all messages, regardless of the type of device. All the fields after LEN are specific to the type of message.
*** Common part ***
NID = Micronet Network ID. At least, it really looks like. The small value of the first byte let me think that it could have a special meaning.
DT = Device Type
2 Wind Transducer
83 Analog Wind Display (bit 7 seems to mean that the device is a display)
81 Dual Display
1 Hull Transmitter
DID = Device ID ? Seems to be unique to each device. Unsure if it has any other meaning.
MID = Message ID - Describe the message and tells the receiver how to decode the specific part of the message.
0x0201 Wind measurements - I bet that 0x02 means "wind"
C? = Looks like a checksum but I did not find the way to calculate it. I observed that ifa single byte increase by one in the previous bytes, this one also increases by one.
LEN = length-1 of the packet in byte. Value duplicated on the two bytes, probably for robustness. It allows to now how many byte we have in the specific part of the message
*** 0x0201 specific part ***
FD1 = This is probably a field descriptor which tells what is the following data (AWS in the example).
AWS = Wind speed in knots*10 coded as 16-bit integer. Just devide by 10 to get speed in knots.
C1 = Field checksum. Addition of the five previous bytes (4 + 5 +5 + 0 + 0 = 0xe)
FD2 = Same as FD1 except for a 5 becoming a 6, probably means AWA instead of AWS
AWA = AWA angle in degrees, coded with a signed 16-bit interger.
C12 = Field checksum. Addition of the five previous bytes (4 + 6 + 5 + 0 + 57 = 0x66)
There is a lot more to discover and will probably come back later with new messages and fields.
For those who are interested in the code which initializes the CC1101, I can provide it by mail.
Best regard.
Rodemfr
Member
Damn, all the spacing have been crunched at publication !
Here are the size of fields :
NID : 3 bytes
DT : 1 bytes
DID : 3 bytes
MID : 2 bytes
?1 : 1 byte
C? : 1 byte
LEN : 2 bytes
FD1 : 3 bytes
AWS : 2 bytes
C1 : 1 bytes
FD2 : 3 bytes
AWA : 2 bytes
C2 : 1 bytes
Here are the size of fields :
NID : 3 bytes
DT : 1 bytes
DID : 3 bytes
MID : 2 bytes
?1 : 1 byte
C? : 1 byte
LEN : 2 bytes
FD1 : 3 bytes
AWS : 2 bytes
C1 : 1 bytes
FD2 : 3 bytes
AWA : 2 bytes
C2 : 1 bytes
nrcoyle
Member
Hi Rodemfr,
looks like you have moved things on from where I was at, whilst I could get the wind data out reliably with my approach, it did bother me than the data straddled bytes, so I suspected something was misaligned.
I have been looking at some saved radio data I have and have struggled to get your syncword to work, but that may be unreliable initial data captures with an RTL-SDR stick, I am not able to visit the boat at the moment to try and capture some new data with your settings.
Incidentally, on the latest module I have been using I tuned in at 869.745 so much closer to your value, I wonder if The previous module had some tuning issues.
I would very much be interested in getting your CC1101 setup code to compare the other settings to those that I am using to see if there are other improvements to be made. I was going to send you a PM with my email address to request the info, but the way this forum works you need to send another couple of messages before it enables the PM function.
Perhaps you could fire off a few more messgaes into this thread.
Cheers,
Neil
looks like you have moved things on from where I was at, whilst I could get the wind data out reliably with my approach, it did bother me than the data straddled bytes, so I suspected something was misaligned.
I have been looking at some saved radio data I have and have struggled to get your syncword to work, but that may be unreliable initial data captures with an RTL-SDR stick, I am not able to visit the boat at the moment to try and capture some new data with your settings.
Incidentally, on the latest module I have been using I tuned in at 869.745 so much closer to your value, I wonder if The previous module had some tuning issues.
I would very much be interested in getting your CC1101 setup code to compare the other settings to those that I am using to see if there are other improvements to be made. I was going to send you a PM with my email address to request the info, but the way this forum works you need to send another couple of messages before it enables the PM function.
Perhaps you could fire off a few more messgaes into this thread.
Cheers,
Neil
Rodemfr
Member
Hi Neil,
I progressed a lot this week-end. I'm now able to decode all the data from my devices (wind, speed, depth, temperature, battery voltage, log & trip data). I'm even able to decode calibration data for various sensor.
I finally found the right sync word for which everything becomes simple : 0x5599. One byte before my previous one.
I'm currently writing a Micronet to NMEA converter on my Teensy to connect to OpenCPN and qtVlm. I created a Github project for this but I keep it private until it reaches a respectable level of maturity. Have you a Github account ? I could give you access to it.
My CC1101 driver is basically the SmartRC -CC1101-Driver but slightly modified to use interrupt and special packet configuration.
Cheers,
Ronan.
I progressed a lot this week-end. I'm now able to decode all the data from my devices (wind, speed, depth, temperature, battery voltage, log & trip data). I'm even able to decode calibration data for various sensor.
I finally found the right sync word for which everything becomes simple : 0x5599. One byte before my previous one.
I'm currently writing a Micronet to NMEA converter on my Teensy to connect to OpenCPN and qtVlm. I created a Github project for this but I keep it private until it reaches a respectable level of maturity. Have you a Github account ? I could give you access to it.
My CC1101 driver is basically the SmartRC -CC1101-Driver but slightly modified to use interrupt and special packet configuration.
Cheers,
Ronan.
Rodemfr
Member
In addition, here is my latest understanding of the protocol. I replaced all spaces by points to avoid forum's software to compress consecutive spaces.
I also attached the original text file.
*************************************************
***.Header.common.to.of.all.Micronet.messages.***
*************************************************
General.format.:
|83.03.77.37|02|03.90.87|02|01|07|5A|18.18|xx.xx.xx.xx....
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|...
|.............MESSAGE.HEADER..............|....PAYLOAD....
NID.=.Network.ID,.is.equal.to.the.Device.ID.of.the.network.main.display
DT.+.DID.=.Device.ID.(4.bytes).-.Unique.number.identifying.the.device..The.first.byte.DT.defines.the.device.type.:
.....DT.-.Device.Type - Several codes have been deducted from display configuration menu
..........0x01.Hull.Transmitter
..........0x02.Wind.Transducer
..........0x03.NMEA.Converter
..........0x04.Mast.Rotation.Sensor
..........0x05.MOB
..........0x83.Analog.Wind.Display
..........0x81.Dual.Display
MI.=.Message.ID.(1.bytes).-.Type.of.the.message..Necessary.for.the.receiver.to.properly.decode.it..
.....0x01.Request.Data
.....0x02.Send.Data
.....0x06.Set.Calibration
.....0x0a.?
.....0x0b.?
SO.=.Source
.....0x01.Measurement/non.display.device
.....0x09.Display.device
DE.=.Destination
.....0x00.Broadcast./.All.devices
.....0x09.Display
CS.=.Check.sum.of.all.previous.bytes.from.NID.to.DE.included.
LEN.=.Length.-.2.of.the.complete.message.in.bytes,.including.payload..Value.duplicated.on.two.bytes.for.robustness.since.it.is.not.covered.by.the.header.checksum.
********************************
***.Message.0x02.(Send.Data).***
********************************
This.message.is.used.to.send.data.from.one.device.to.one.another..It.is.a.response.to."Request.Data".message.sent.by.the.main
display.to.collect.data.from.all.sensors..It.sends.a.variable.number.of.fields.depending.on.the.Device.Type.and.its.available
sensors.
Each.field.is.coded.the.same.way.but.with.variable.size.and.type..The.number.of.fields.can.be.dynamically.discovered.during
decoding.by.comparing.each.field.position.to.the.complete.message.size.
Message.examples.:
Message.from.wind.transducer
|83.03.77.37|02|03.90.87|02|01|09|5C|18.18|04.05.05.00.2C.3A|04.06.05.FF.FB.09|
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|
Message.sent.by.an.analog.wind.display
|83.03.77.37|83|03.77.37|02|09|00|73|1A.1A|05.21.05.00.00.09.34|05.22.05.00.64.09.99|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.TWS.|??|FC|FF|FI|FP|.TWA.|??|FC|
|.............MESSAGE.HEADER..............|.......FIELD1.......|.......FIELD2.......|
Message.sent.by.a.dual.display
|83.03.77.37|81|03.70.82|02|09|00|B5|1A.1A|05|21|05|00.00|09|34|05.22.05.00.33|09|68|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.TWS.|??|FC|FF|FI|FP|.TWA.|??|FC|
|.............MESSAGE.HEADER..............|.......FIELD1.......|.......FIELD2.......|
Message.sent.by.a.hull.transmitter
|83.03.77.37|01|0B.C0.22|02|01|09|2E|49.49|04|04|05|13.89|A9|04|1B|05|00.89|AD|05|21|05|00.00|06|31|05|22|05|FF.F5|06|26|04|01|05|00.BB|C5|0A|02|05|00.00.00.95|00.00.00.1C|C2|03|03|05|25|30|04|05|03|00.00|0C|04|06|03|FF.F5|01|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.DPT.|FC|FF|FI|FP|.VCC.|FC|FF|FI|FP|.AWS.|??|FC|FF|FI|FP|.AWA.|??|FC|FF|FI|FP|.SPD.|FC|FF|FI|FP|...TRIP....|....LOG....|FC|FF|FI|FP|T.|FC|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|.......FIELD3.......|.......FIELD4.......|.....FIELD5......|..............FIELD6...............|....FIELD7....|......FIELD8.....|.....FIELD9......|
FT.=.Field.format
.....0x04.Total.field.description.is.on.6.bytes,.including.CRC..Value.is.on.a.16-bits.integer.
.....0x05.Total.field.description.is.on.7.bytes,.including.CRC..In.this.case.there.is.an.extra.byte.after.the.16-bit.integer.value.which.is.unidentified.yet.
.....0x0a.Total.field.description.is.on.12.bytes,.including.CRC..Two.values.are.encoded.on.a.32-bit.integer.each.
FI.=.Field.ID
.....0x01.SPD*100(KT)
.....0x02.TRIP*100(NM).+.LOG*10(NM)
.....0x03.T*2(degC)
.....0x04.DPT*10(FT).................A.value.of.5001(500.1ft).is.given.by.the.hull.transmitter.when.depth.is.not.available.
.....0x05.AWS*10(KT).
.....0x06.AWA(DEG)
.....0x1b.VCC*10(V)
.....0x21.AWS*10(KT).................Seems.the.same.than.0x05.?
.....0x22.AWA(DEG)...................Seems.the.same.than.0x06.?
FP.=.Field.Property.??
.....0x05.It.seems.to.be.the.value.used.when.the.data.comes.from.the.measuring.sensor
.....0x03.It.seems.to.be.the.value.used.when.the.data.comes.from.a.repeater.(i.e..the.main.display.or.hull.transmitter)
FC.=.Field.checksum..Sum.of.the.all.the.byte.of.the.field.
**************************************
***.Message.0x06.(Set.Calibration).***
**************************************
Example.:.Wind.direction.calibration.+10.deg
|83.03.77.37|83|03.77.37|06|09|09|80|13.13|FF|07|02|0A.00|04.16|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|.VA..|SQ|CS|
|.............MESSAGE.HEADER..............|.....CORRECTION.....|
Example.:.Wind.Speed.Calibration.+7.deg
|83.03.77.37|83|03.77.37|06|09|00|77|12.12|FF.06.01.07.0B.18|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|VA|SQ|CS|
|.............MESSAGE.HEADER..............|....CORRECTION...|
Example.:.Speed.filtering.level.MED
|83.03.77.37|81|03.70.82|06|09|09|C2|12.12|FF|04|01|20|0E|32|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|VA|SQ|CS|
|.............MESSAGE.HEADER..............|....CORRECTION...|
PI.Parameter.ID
...0x04.Speed.filtering.level
......VA.=.0x00.:.AUTO
......VA.=.0x10.:.SLOW
......VA.=.0x20.:.MED
......VA.=.0x30.:.FAST
...0x06.Wind.speed.factor
......VA.=.Speed.correction.as.signed.8bit.interger.in.degrees
...0x07.Wind.direction.offset
......VA.=.An.signed.16-bit.integer.in.degrees./!\.LITTLE.ENDIAN.VALUE./!\
PL.Parameter.Length.?.Seems.to.be.the.number.of.bytes.on.wich.VA.is.coded.
I also attached the original text file.
*************************************************
***.Header.common.to.of.all.Micronet.messages.***
*************************************************
General.format.:
|83.03.77.37|02|03.90.87|02|01|07|5A|18.18|xx.xx.xx.xx....
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|...
|.............MESSAGE.HEADER..............|....PAYLOAD....
NID.=.Network.ID,.is.equal.to.the.Device.ID.of.the.network.main.display
DT.+.DID.=.Device.ID.(4.bytes).-.Unique.number.identifying.the.device..The.first.byte.DT.defines.the.device.type.:
.....DT.-.Device.Type - Several codes have been deducted from display configuration menu
..........0x01.Hull.Transmitter
..........0x02.Wind.Transducer
..........0x03.NMEA.Converter
..........0x04.Mast.Rotation.Sensor
..........0x05.MOB
..........0x83.Analog.Wind.Display
..........0x81.Dual.Display
MI.=.Message.ID.(1.bytes).-.Type.of.the.message..Necessary.for.the.receiver.to.properly.decode.it..
.....0x01.Request.Data
.....0x02.Send.Data
.....0x06.Set.Calibration
.....0x0a.?
.....0x0b.?
SO.=.Source
.....0x01.Measurement/non.display.device
.....0x09.Display.device
DE.=.Destination
.....0x00.Broadcast./.All.devices
.....0x09.Display
CS.=.Check.sum.of.all.previous.bytes.from.NID.to.DE.included.
LEN.=.Length.-.2.of.the.complete.message.in.bytes,.including.payload..Value.duplicated.on.two.bytes.for.robustness.since.it.is.not.covered.by.the.header.checksum.
********************************
***.Message.0x02.(Send.Data).***
********************************
This.message.is.used.to.send.data.from.one.device.to.one.another..It.is.a.response.to."Request.Data".message.sent.by.the.main
display.to.collect.data.from.all.sensors..It.sends.a.variable.number.of.fields.depending.on.the.Device.Type.and.its.available
sensors.
Each.field.is.coded.the.same.way.but.with.variable.size.and.type..The.number.of.fields.can.be.dynamically.discovered.during
decoding.by.comparing.each.field.position.to.the.complete.message.size.
Message.examples.:
Message.from.wind.transducer
|83.03.77.37|02|03.90.87|02|01|09|5C|18.18|04.05.05.00.2C.3A|04.06.05.FF.FB.09|
|....NUID...|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|
Message.sent.by.an.analog.wind.display
|83.03.77.37|83|03.77.37|02|09|00|73|1A.1A|05.21.05.00.00.09.34|05.22.05.00.64.09.99|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.TWS.|??|FC|FF|FI|FP|.TWA.|??|FC|
|.............MESSAGE.HEADER..............|.......FIELD1.......|.......FIELD2.......|
Message.sent.by.a.dual.display
|83.03.77.37|81|03.70.82|02|09|00|B5|1A.1A|05|21|05|00.00|09|34|05.22.05.00.33|09|68|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.TWS.|??|FC|FF|FI|FP|.TWA.|??|FC|
|.............MESSAGE.HEADER..............|.......FIELD1.......|.......FIELD2.......|
Message.sent.by.a.hull.transmitter
|83.03.77.37|01|0B.C0.22|02|01|09|2E|49.49|04|04|05|13.89|A9|04|1B|05|00.89|AD|05|21|05|00.00|06|31|05|22|05|FF.F5|06|26|04|01|05|00.BB|C5|0A|02|05|00.00.00.95|00.00.00.1C|C2|03|03|05|25|30|04|05|03|00.00|0C|04|06|03|FF.F5|01|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.DPT.|FC|FF|FI|FP|.VCC.|FC|FF|FI|FP|.AWS.|??|FC|FF|FI|FP|.AWA.|??|FC|FF|FI|FP|.SPD.|FC|FF|FI|FP|...TRIP....|....LOG....|FC|FF|FI|FP|T.|FC|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|.......FIELD3.......|.......FIELD4.......|.....FIELD5......|..............FIELD6...............|....FIELD7....|......FIELD8.....|.....FIELD9......|
FT.=.Field.format
.....0x04.Total.field.description.is.on.6.bytes,.including.CRC..Value.is.on.a.16-bits.integer.
.....0x05.Total.field.description.is.on.7.bytes,.including.CRC..In.this.case.there.is.an.extra.byte.after.the.16-bit.integer.value.which.is.unidentified.yet.
.....0x0a.Total.field.description.is.on.12.bytes,.including.CRC..Two.values.are.encoded.on.a.32-bit.integer.each.
FI.=.Field.ID
.....0x01.SPD*100(KT)
.....0x02.TRIP*100(NM).+.LOG*10(NM)
.....0x03.T*2(degC)
.....0x04.DPT*10(FT).................A.value.of.5001(500.1ft).is.given.by.the.hull.transmitter.when.depth.is.not.available.
.....0x05.AWS*10(KT).
.....0x06.AWA(DEG)
.....0x1b.VCC*10(V)
.....0x21.AWS*10(KT).................Seems.the.same.than.0x05.?
.....0x22.AWA(DEG)...................Seems.the.same.than.0x06.?
FP.=.Field.Property.??
.....0x05.It.seems.to.be.the.value.used.when.the.data.comes.from.the.measuring.sensor
.....0x03.It.seems.to.be.the.value.used.when.the.data.comes.from.a.repeater.(i.e..the.main.display.or.hull.transmitter)
FC.=.Field.checksum..Sum.of.the.all.the.byte.of.the.field.
**************************************
***.Message.0x06.(Set.Calibration).***
**************************************
Example.:.Wind.direction.calibration.+10.deg
|83.03.77.37|83|03.77.37|06|09|09|80|13.13|FF|07|02|0A.00|04.16|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|.VA..|SQ|CS|
|.............MESSAGE.HEADER..............|.....CORRECTION.....|
Example.:.Wind.Speed.Calibration.+7.deg
|83.03.77.37|83|03.77.37|06|09|00|77|12.12|FF.06.01.07.0B.18|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|VA|SQ|CS|
|.............MESSAGE.HEADER..............|....CORRECTION...|
Example.:.Speed.filtering.level.MED
|83.03.77.37|81|03.70.82|06|09|09|C2|12.12|FF|04|01|20|0E|32|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|??|PI|PL|VA|SQ|CS|
|.............MESSAGE.HEADER..............|....CORRECTION...|
PI.Parameter.ID
...0x04.Speed.filtering.level
......VA.=.0x00.:.AUTO
......VA.=.0x10.:.SLOW
......VA.=.0x20.:.MED
......VA.=.0x30.:.FAST
...0x06.Wind.speed.factor
......VA.=.Speed.correction.as.signed.8bit.interger.in.degrees
...0x07.Wind.direction.offset
......VA.=.An.signed.16-bit.integer.in.degrees./!\.LITTLE.ENDIAN.VALUE./!\
PL.Parameter.Length.?.Seems.to.be.the.number.of.bytes.on.wich.VA.is.coded.
Rodemfr
Member
I realized just after posting that there is still an error in my description : everywhere you see TWS or TWA, this is in fact AWA & AWS. True Wind seems not to travel on the network. Display are probably calculating it by themselves.
tty
Member
C? is calculated by adding up the first 11 bytes limiting the result to a 1 byte register.
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 14 02
01 + 0A = 0B
0B + 8B = 96
96 + 60 = F6
F6 + 81 = 177 (truncated to 77)
77 + 03 = 7A
7A + 61 = DB
DB + 7C = 157 (truncated to 57)
57+ 01 = 58
58 + 09 = 61
61 + 00 = 61
I believe the 0x07 message type is an alarm message. Here's an example of a "no voltage" alarm and it's ack.
27.08068325 - 27.08459250 Received 19 bytes(0x13) Freq 0.9216 ORDERED.
01 0A 8B 60 81 03 61 7C 06 09 00 66 10 10 E5 00 01 E6 84
27.08776081 - 27.09101919 Transmitted 14 bytes(0xe) Freq 1.2288 ORDERED.
01 0A 8B 60 01 0B 8B 60 07 01 09 FE 0C 0C
27.09313863 - 27.09661494 Received 15 bytes(0xf) Freq 0.9216 ORDERED.
01 0A 8B 60 81 03 61 7C 07 09 00 67 0C 0C F4
Here is a few 0x0a/0b interactions. Not sure what they're for either.
49.12778444 - 49.13125813 Received 16 bytes(0x10) Freq 916.0704 ORDERED.
01 0A 8B 60 81 03 61 7C 0A 09 00 6A 0C 0C 19
49.13486338 - 49.13833350 Transmitted 16 bytes(0x10) Freq 915.88845 ORDERED.
01 0A 8B 60 01 0B 8B 60 0B 01 09 02 0E 0E 00 00
83.13690381 - 83.14031825 Received 16 bytes(0x10) Freq 916.0704 ORDERED.
01 0A 8B 60 81 03 61 7C 0A 09 00 6A 0C 0C 10 A0
83.14402581 - 83.14749294 Transmitted 16 bytes(0x10) Freq 915.88845 ORDERED.
01 0A 8B 60 01 0B 8B 60 0B 01 09 02 0E 0E 00 00
117.14574156 - 117.14921831 Received 16 bytes(0x10) Freq 916.0704 ORDERED.
01 0A 8B 60 81 03 61 7C 0A 09 00 6A 0C 0C 1E
117.15282106 - 117.15628900 Transmitted 16 bytes(0x10) Freq 915.88845 ORDERED.
01 0A 8B 60 01 0B 8B 60 0B 01 09 02 0E 0E 00 00
Here's an 0x03 message. Might be data unavailable as it was given as a response to a data request. Only seen it once so unsure.
11.36454906 - 11.36906919 Received 24 bytes(0x18) Freq 916.0704 ORDERED.
01 0A 8B 60 81 03 61 7C 01 09 00 61 14 14 81 03 61 7C 08 00 00 69 71 0A
11.37797481 - 11.38154631 Transmitted 17 bytes(0x11) Freq 915.88845 ORDERED.
01 0A 8B 60 01 0B 8B 60 03 01 09 FA 0F 0F 00 1A 1A
How hard is the cc1101 to use? I'm finding the cc1000 a very temperamental beast. Have you seen when a device is expecting a message but doesn't get one it'll pump out a preamble for ~30ms with no message following? They use it to calibrate each other's averaging filter(pg 19 of the datasheet). It's a mechanic you might have to work into your program to keep the micronet healthy. Right now I'm using long preambles. Works for the short term. Keep up the great work!
nrcoyle
Member
Great work,
It is still not allowing me to PM you, but my Github username is coylen.
I am working on a system based on a ESP32 which multiplexes physical NMEA and Seatalk inputs with the Tacktick wind and an old fluxgate compass and multiplexes it all up over UDP for my navigation tablet to pick up. Like you it is currently in a private repository, I only dabble in code by trial and error, so it is all a bit of a mess.
Would be good to have a look at each others ideas, although I suspect that I will gain more than you will as you seem to be streets ahead of me.
Neil
It is still not allowing me to PM you, but my Github username is coylen.
I am working on a system based on a ESP32 which multiplexes physical NMEA and Seatalk inputs with the Tacktick wind and an old fluxgate compass and multiplexes it all up over UDP for my navigation tablet to pick up. Like you it is currently in a private repository, I only dabble in code by trial and error, so it is all a bit of a mess.
Would be good to have a look at each others ideas, although I suspect that I will gain more than you will as you seem to be streets ahead of me.
Neil
Rodemfr
Member
Indeed, we are working on the same topics. Together we are better : Let's share all of this...
I invited you on my Github repo. Feel free to use everything you want.
On my side, I'm still concentrating on the decoding of Micronet. My goal is close to yours : connect my Raymarine Wireless System to OpenCPN or qtVlm or a tablet. I'm currently working with a Teensy board but once all of this will be functionnal I will probably switch to an Arduino Nano BLE which will allow me to broadcast my NMEA stream through Bluetooth. This arduino support up to 21V at input, allowing a direct connection to the boat electrical circuit.
Rodemfr
Member
Excellent ! I will have a deeper look to this this evening and will answer the questions ... if I can !
Rodemfr
Member
Yes, and it allowed me to understand that my sync word was wrong and was eating the first byte of the header.
I don't know CC1000 interface but I'm not sure CC1101 is easier to configure. All the analog and demodulation stuff is probably similar but it has an additionnal packet management stage which is not well suited for Micronet, so I have to handle a lot of things manually, as on CC1000 I guess.
I did not observe the preampble without packet, but I did not record more than a few seconds of messages with my RTL-SDR dongle and URH SW. For now, I'm only working at listening the network, so I let the other deices handle this type of stuff.
Thanks a lot for all your logs, it's gold !
Ronan.
tty
Member
You might find this helpful. It's the full comms between the MCU and CC1000 in a hull transmitter from power on. It has programming, tuning and calibration, finding a display, sending/receiving data etc.
Rodemfr
Member
Hi All,
Here it is, a Micronet to NMEA converter on a Teensy/Arduino board with a 5€ CC1101 based board : Rodemfr/MicronetToNMEA
For those interested, I maintain a file with my current understanding of Micronet protocol : Rodemfr/MicronetToNMEA
A list of the NMEA sentences generated :
- MWV : Apparent & True Wind (speed + direction)
- DPT : Depth
- MTW : Water Temperature
- VHW : Speed On Water
- VLW : Log and Trip distance
Tested successfully on OpenCPN and qtVlm.
It is able to catch calibration data from Micronet devices (i.e. corrective factors for various parameters) and to save them in EEPROM.
A manual is still to write, It will arrive probably in a few days.
It only support transducers I own : Wind Transducer, Depth Sounder, Speed and Water temperature. If anyone has a Tacktick electronic compass or T122 NMEA converter with a GPS, it would be great to enhance the number of devices supported by MicronetToNMEA. You can use the embedded scan feature to capture all the traffic of your system.
I just ordered an Arduino Nano BLE with bluetooth to be able to directly connect a tablet to the TackTick system ... wireless !
Ronan.
Here it is, a Micronet to NMEA converter on a Teensy/Arduino board with a 5€ CC1101 based board : Rodemfr/MicronetToNMEA
For those interested, I maintain a file with my current understanding of Micronet protocol : Rodemfr/MicronetToNMEA
A list of the NMEA sentences generated :
- MWV : Apparent & True Wind (speed + direction)
- DPT : Depth
- MTW : Water Temperature
- VHW : Speed On Water
- VLW : Log and Trip distance
Tested successfully on OpenCPN and qtVlm.
It is able to catch calibration data from Micronet devices (i.e. corrective factors for various parameters) and to save them in EEPROM.
A manual is still to write, It will arrive probably in a few days.
It only support transducers I own : Wind Transducer, Depth Sounder, Speed and Water temperature. If anyone has a Tacktick electronic compass or T122 NMEA converter with a GPS, it would be great to enhance the number of devices supported by MicronetToNMEA. You can use the embedded scan feature to capture all the traffic of your system.
I just ordered an Arduino Nano BLE with bluetooth to be able to directly connect a tablet to the TackTick system ... wireless !
Ronan.
tty
Member
@Rodemfr
Do you have a capture of the 0x03 water temp message, lat/long message, sog message, or cog message you can share? I have bidirectional communication with my dual display and get most fields to populate but haven't found those ones yet. Here's some fields missing from your list:
0x07 - 3 byte HDG
0x0B - 3 byte XTE
0x0C - 3 byte Time
0x0D - 7 byte Date
0x18 - 3 byte VMG-WP
Do you have a capture of the 0x03 water temp message, lat/long message, sog message, or cog message you can share? I have bidirectional communication with my dual display and get most fields to populate but haven't found those ones yet. Here's some fields missing from your list:
0x07 - 3 byte HDG
0x0B - 3 byte XTE
0x0C - 3 byte Time
0x0D - 7 byte Date
0x18 - 3 byte VMG-WP
Rodemfr
Member
I have an example of water temp, but not of cog/sog/lat/lon :
|83.03.77.37|01|0B.C0.22|02|01|09|2E|49.49|04|04|05|13.89|A9|04|1B|05|00.89|AD|05|21|05|00.00|06|31|05|22|05|FF.F5|06|26|04|01|05|00.BB|C5|0A|02|05|00.00.00.95|00.00.00.1C|C2|03|03|05|25|30|04|05|03|00.00|0C|04|06|03|FF.F5|01|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.DPT.|FC|FF|FI|FP|.VCC.|FC|FF|FI|FP|.AWS.|??|FC|FF|FI|FP|.AWA.|??|FC|FF|FI|FP|.SPD.|FC|FF|FI|FP|...TRIP....|....LOG....|FC|FF|FI|FP|T.|FC|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|.......FIELD3.......|.......FIELD4.......|.....FIELD5......|..............FIELD6...............|....FIELD7....|......FIELD8.....|.....FIELD9......|
Water temp is on field 7 in this example.
You found new fields, excellent ! But how did you find them, from a microcompass or racemaster ?
I did'nt have time to parse your log yet. I will do this this evening...
|83.03.77.37|01|0B.C0.22|02|01|09|2E|49.49|04|04|05|13.89|A9|04|1B|05|00.89|AD|05|21|05|00.00|06|31|05|22|05|FF.F5|06|26|04|01|05|00.BB|C5|0A|02|05|00.00.00.95|00.00.00.1C|C2|03|03|05|25|30|04|05|03|00.00|0C|04|06|03|FF.F5|01|
|....NID....|DT|..DID...|MI|SO|DE|CS|.LEN.|FF|FI|FP|.DPT.|FC|FF|FI|FP|.VCC.|FC|FF|FI|FP|.AWS.|??|FC|FF|FI|FP|.AWA.|??|FC|FF|FI|FP|.SPD.|FC|FF|FI|FP|...TRIP....|....LOG....|FC|FF|FI|FP|T.|FC|FF|FI|FP|.AWS.|FC|FF|FI|FP|.AWA.|FC|
|.............MESSAGE.HEADER..............|......FIELD1.....|......FIELD2.....|.......FIELD3.......|.......FIELD4.......|.....FIELD5......|..............FIELD6...............|....FIELD7....|......FIELD8.....|.....FIELD9......|
Water temp is on field 7 in this example.
You found new fields, excellent ! But how did you find them, from a microcompass or racemaster ?
I did'nt have time to parse your log yet. I will do this this evening...