tty
Member
No idea. You're probably going to have to write a decoder to do anything useful. What are your intentions?
Raymarine's Micronet
- Thread starter Gixer
- Start date
No idea. You're probably going to have to write a decoder to do anything useful. What are your intentions?
Booster
New member
In my opinion rtl_433 is fine for gathering the signal but has few weaknesses in analyzing the FSK_PCM decoded bursts.
In meantime I switched over to the URH tool with more success.
With the help of Rodemfr (Thank you!) protocol document I was able to decode Hull transmitter answer. There are still few problems in recognizing sync word from display request (see above the 5566 instead 5599. I must tweak the radio and sampling parameter next days.
My intention is to add GPS data LAT, SOG, Time and Date without to by the expensive T122. Has someone used a simpler uC to control the CC1101 like ESP32?
In meantime I switched over to the URH tool with more success.
With the help of Rodemfr (Thank you!) protocol document I was able to decode Hull transmitter answer. There are still few problems in recognizing sync word from display request (see above the 5566 instead 5599. I must tweak the radio and sampling parameter next days.
My intention is to add GPS data LAT, SOG, Time and Date without to by the expensive T122. Has someone used a simpler uC to control the CC1101 like ESP32?
nrcoyle
Member
Your first message showing 5566 just needs to left shift 2 bits, I think you can force URH to find the sync word in the analysis section which should sort out the alignment and make more sense.
Booster
New member
You are right, the bit shift has to do with the settling of the synchronization phase of both transmitter (hull and display).
With screwing rtl-sdr parameter I got now better results:
Question to all: I would like to waive the Bluetooth connection and only try to connect the GNSS modul. Is it possible to use a simpler uC + CC1101 combination, e.g. ESP32? Which requirements are necessary to the uC?
With screwing rtl-sdr parameter I got now better results:
Question to all: I would like to waive the Bluetooth connection and only try to connect the GNSS modul. Is it possible to use a simpler uC + CC1101 combination, e.g. ESP32? Which requirements are necessary to the uC?
Rodemfr
Member
Hi Booster,
I did not test any ESP32 board, I only had a Teensy 3.5 board when I started to investigate the protocol, that's why I chose this one.
However, after the suggestion of ncoyle , I had a look to ESP32 based boards and this should work fine with minor adaptations of SW. Adafruit is selling Arduino compatible ESP32 boards which should work fine for this. Just be aware that, if you plan to use MicronetToNMEA SW from Github, you will likely have to do some adaptations of SW, especially w.r.t EEPROM which is often an issue on Arduino boards.
I will help you anyway, I'm interested to see the SW running on a ESP32.
I did not test any ESP32 board, I only had a Teensy 3.5 board when I started to investigate the protocol, that's why I chose this one.
However, after the suggestion of ncoyle , I had a look to ESP32 based boards and this should work fine with minor adaptations of SW. Adafruit is selling Arduino compatible ESP32 boards which should work fine for this. Just be aware that, if you plan to use MicronetToNMEA SW from Github, you will likely have to do some adaptations of SW, especially w.r.t EEPROM which is often an issue on Arduino boards.
I will help you anyway, I'm interested to see the SW running on a ESP32.
tty
Member
Yes. I'd suggest an ESP32-WROOM32 or similar. They have a CAN controller baked in so interfacing with NMEA2000/SeaTalkNG is easy. You only need a transceiver chip for level shifting. Bonus for Raymarine users, the whole thing can be powered off the stNG bus.
Booster
New member
Thank you Rodemfr,
I am just starting with Arduino and tried your files to compile. Few question:
- you are using avr/eeprom.h which is not available in my installation. But you have a Teensy board, not a AVR board. Is the lib compatible with your eeprom?
- Did you use a special library for the BT HC-06 modul? Other libs I have to include?
- I checked the transceiver examples from ELECHOUSE_CC1101_SRC_DRV.h which worked very well on my NodeCPU board. But compiling your project I got massive problems with all the "byte" usage in certain libs. The typedef in Arduino.h seems not active. Any clue?
Rodemfr
Member
Hi Booster,
Sorry for the late answer.
You are right, avr/eeprom.h is a bad usage of EEPROM API. I changed the code to use the "official" EEPROM library (EEPROM.h). It is already in the github repo now. You just have to pull the project and to ensure that EEPROM library is added to your project.
For HC-06, I did not use any special library. The IC is supposed to just convert an UART flow into BT flow. However, I temporarily disabled it because I was getting problems when using it in a permanent full-duplex mode (i.e. when there is a permanent flow from Micronet and a permanent flow from qtVlm). I discovered that my HC-06 is not an HC-06 but another clone. I suspect that this is the source of my problem, but I'm not sure.
For the compilation problems with Sloeber, check that all required libraries are properly added to your project : SPI, SmartRC-CC1101-Driver and EEPROM. This should solve your issue.
Best regars,
Rodemfr.
Sorry for the late answer.
You are right, avr/eeprom.h is a bad usage of EEPROM API. I changed the code to use the "official" EEPROM library (EEPROM.h). It is already in the github repo now. You just have to pull the project and to ensure that EEPROM library is added to your project.
For HC-06, I did not use any special library. The IC is supposed to just convert an UART flow into BT flow. However, I temporarily disabled it because I was getting problems when using it in a permanent full-duplex mode (i.e. when there is a permanent flow from Micronet and a permanent flow from qtVlm). I discovered that my HC-06 is not an HC-06 but another clone. I suspect that this is the source of my problem, but I'm not sure.
For the compilation problems with Sloeber, check that all required libraries are properly added to your project : SPI, SmartRC-CC1101-Driver and EEPROM. This should solve your issue.
Best regars,
Rodemfr.
Booster
New member
Thanks Rodemfr,
no problem with delay - its sailing season
even though the weather is a bit strange this year here in Germany.
I got now ESP32 and CC1101 boards and started first attempts. BT I will skip at first. A macro to do this would be helpful.
EEPROM API is easier to use under the Arduino IDE which I am using. I saw your last commit and noticed a byte-wise read and write operation instead of entire block operation before. Don't know if the NV lifetime is affected because our EEPROM is emulated only.
I read that for ESP32 EEPROM is depreciated and Preferences.h is recommended and is part of ESP32 board lib. So I used this. Perhaps you can take a look in the attached file and comment.
Now I am fighting about the different class definitions for SPI and Serial interfaces e.g.:
I think pin configuration should all defined in the Serial and SPI begin statement. Our board libraries are just different.
At the moment I have a conflict with SmartRC-CC1101-Driver GDO0 pin definition for ESP32 - it stands on GPIO2 in their example. But this is also defined for ESP32 LED_BUILTIN. Don't know which to change.
no problem with delay - its sailing season
even though the weather is a bit strange this year here in Germany.I got now ESP32 and CC1101 boards and started first attempts. BT I will skip at first. A macro to do this would be helpful.
EEPROM API is easier to use under the Arduino IDE which I am using. I saw your last commit and noticed a byte-wise read and write operation instead of entire block operation before. Don't know if the NV lifetime is affected because our EEPROM is emulated only.
I read that for ESP32 EEPROM is depreciated and Preferences.h is recommended and is part of ESP32 board lib. So I used this. Perhaps you can take a look in the attached file and comment.
Now I am fighting about the different class definitions for SPI and Serial interfaces e.g.:
Code:
Main.cpp:110:14: error: 'class HardwareSerial' has no member named 'setTX'
GNSS_SERIAL.setTX(GNSS_TX_PIN);
^
Main.cpp:116:6: error: 'class SPIClass' has no member named 'setMOSI'
SPI.setMOSI(MOSI_PIN);I think pin configuration should all defined in the Serial and SPI begin statement. Our board libraries are just different.
At the moment I have a conflict with SmartRC-CC1101-Driver GDO0 pin definition for ESP32 - it stands on GPIO2 in their example. But this is also defined for ESP32 LED_BUILTIN. Don't know which to change.
Rodemfr
Member
Hi Booster,
You are right for Flash lifetime. I think the entire flash page is written at each byte, which is not good at all. But I did not find any alternative to byte writing without using avr/eeprom.h.
Your version with Preference.h is superior. It is unfortunately not working for Teensy which doesn't have it implemented.
For setTX and setMOSI, these are Teensy specific API added to enable usage of the CPU configurability in term of IOs. I don(t know ESP32 but I suspect that IO configuration is not as flexible.
For GD0, it can be onthe same pin than the LED, the only important thing is than it must be configured as input. It simply means that your led will blink at each CC1101 interrupt.
Best regards,
Rodemfr.
You are right for Flash lifetime. I think the entire flash page is written at each byte, which is not good at all. But I did not find any alternative to byte writing without using avr/eeprom.h.
Your version with Preference.h is superior. It is unfortunately not working for Teensy which doesn't have it implemented.
For setTX and setMOSI, these are Teensy specific API added to enable usage of the CPU configurability in term of IOs. I don(t know ESP32 but I suspect that IO configuration is not as flexible.
For GD0, it can be onthe same pin than the LED, the only important thing is than it must be configured as input. It simply means that your led will blink at each CC1101 interrupt.
Best regards,
Rodemfr.
Booster
New member
Hi Rodemfr,
got it compiled:
Der Sketch verwendet 467114 Bytes (35%) des Programmspeicherplatzes. Das Maximum sind 1310720 Bytes.
Globale Variablen verwenden 25360 Bytes (7%) des dynamischen Speichers, 302320 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.
But running it I got memory errors (I assume) and steadily reboots on a pure ESP32 board, w/o transceiver and GNSS:
Must look more on specific pin configuration.
BTW - EEPROM.h shows more functionality as only single byte handling (this are arrays):
size_t readBytes(int address, void * value, size_t maxLen);
size_t writeBytes(int address, const void* value, size_t len);
Regards,
Dietmar
Edit: Problem solved - ESP-WROOM32 board Serial1 interface standard GPIO9 and 10 are used by internal flash. Switching to RX=27 and TX=26 fixed the problem.
got it compiled:
Der Sketch verwendet 467114 Bytes (35%) des Programmspeicherplatzes. Das Maximum sind 1310720 Bytes.
Globale Variablen verwenden 25360 Bytes (7%) des dynamischen Speichers, 302320 Bytes für lokale Variablen verbleiben. Das Maximum sind 327680 Bytes.
But running it I got memory errors (I assume) and steadily reboots on a pure ESP32 board, w/o transceiver and GNSS:
Code:
TPH⸮⸮⸮000001d
EXCVADDR: 0x0800002c LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
Backtrace: 0x40113dbf:0x3ffb1f60 0x400d2f6b:0x3ffb1f80 0x400d68b2:0x3ffb1fb0 0x4008636a:0x3ffb1fd0
Rebooting...
$ "j=|⸮⸮⸮D⸮D⸮⸮⸮!"j⸮ґ"NE"⸮Zj⸮Z⸮ґ"sZ⸮*}P)^⸮T⸮⸮)^⸮T⸮։YPC⸮(^⸮D։Ix⸮E"D⸮YR⸮
⸮F⸮Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x40113dbf PS : 0x00060330 A0 : 0x800d2f6e A1 : 0x3ffb1f60
A2 : 0x3ffc1454 A3 : 0x3ffbdbb4 A4 : 0x0800001c A5 : 0x00000009
A6 : 0x00000009 A7 : 0x00000000 A8 : 0x00009600 A9 : 0x0000000a
A10 : 0x3ffbdd14 A11 : 0x0000000a A12 : 0x3ffbdd14 A13 : 0x00000009
A14 : 0x0000000a A15 : 0x00000004 SAR : 0x00000016 EXCCAUSE: 0x0000001d
EXCVADDR: 0x0800002c LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000Must look more on specific pin configuration.
BTW - EEPROM.h shows more functionality as only single byte handling (this are arrays):
size_t readBytes(int address, void * value, size_t maxLen);
size_t writeBytes(int address, const void* value, size_t len);
Regards,
Dietmar
Edit: Problem solved - ESP-WROOM32 board Serial1 interface standard GPIO9 and 10 are used by internal flash. Switching to RX=27 and TX=26 fixed the problem.
Last edited:
Booster
New member
Hi Rodemfr,
my setup with esp32+cc1101 is now working. I can reach the menus and try certain things. Looking for an idea transmitting Micronet messages for test purpose before I start to connect to the dual display in the boat.
One question regarding frequency programming: Your setting for basic frequency in Main.cpp is 869,778MHz - 34kHz. Why you subtract the freq deviation of the 2-FSK?
From CC1101 datasheet:
BTW - my finding with my 45ppm corrected RTL-SDR stick is 869,835MHz.
Regards,
Dietmar
my setup with esp32+cc1101 is now working. I can reach the menus and try certain things. Looking for an idea transmitting Micronet messages for test purpose before I start to connect to the dual display in the boat.
One question regarding frequency programming: Your setting for basic frequency in Main.cpp is 869,778MHz - 34kHz. Why you subtract the freq deviation of the 2-FSK?
From CC1101 datasheet:
BTW - my finding with my 45ppm corrected RTL-SDR stick is 869,835MHz.
Regards,
Dietmar
Rodemfr
Member
Hi Booster,
Concerning the EEPROM, Teensy implementation of EEPROM.h doesn't have readBytes & writeBytes functions, I can't use them without changing my board.
Concerning frequency, I initially set the frequency to the center with a deviation of 32kHz, but I was getting very bad recption/emission quality. I used RTL-SDR dongle to compare the signal produced by my cc1101 and the one from my display. I discovered that the frequency of my CC1101 wasn't matching. I did not go throuh the entire datasheet of CC1101 so I'm not sure why I had to change these values, but I suspect ELECHOUSE driver not to properly configure CC1101. A way to check this would be to rewrite a simple driver, dedicated to Micronet frequency, using register values from TI's SmartRF studio. I didn't had time to do this before starting my navigation season...
Concerning the EEPROM, Teensy implementation of EEPROM.h doesn't have readBytes & writeBytes functions, I can't use them without changing my board.
Concerning frequency, I initially set the frequency to the center with a deviation of 32kHz, but I was getting very bad recption/emission quality. I used RTL-SDR dongle to compare the signal produced by my cc1101 and the one from my display. I discovered that the frequency of my CC1101 wasn't matching. I did not go throuh the entire datasheet of CC1101 so I'm not sure why I had to change these values, but I suspect ELECHOUSE driver not to properly configure CC1101. A way to check this would be to rewrite a simple driver, dedicated to Micronet frequency, using register values from TI's SmartRF studio. I didn't had time to do this before starting my navigation season...
Last edited:
Booster
New member
Hello Rodemfr,
thanks for answering. Yes, that is what I have learned - the libs are not unique, they are board dependent.
I investigated my cc1101 with same approach and found more extreme deviations. Setting to 869,8M will give 869,875M in center of the 2-FM signal. I will check it more in detail this week perhaps with SmartRF studio or similar.
But one more question. My setup with Menu 2 found my network with "10AC012", leading 0 is skipped. The ID 0x010ac012 is correct, I see it in all my scanned messages. But what should I give as ID in Menu 3. I mean the format, the hex string with or without 0x? I tried different things, but it seems prog can not leave the first while loop in MenuAttachNetwork independent I give enter or push the send Button.
Thanks again,
Dietmar
thanks for answering. Yes, that is what I have learned - the libs are not unique, they are board dependent.
I investigated my cc1101 with same approach and found more extreme deviations. Setting to 869,8M will give 869,875M in center of the 2-FM signal. I will check it more in detail this week perhaps with SmartRF studio or similar.
But one more question. My setup with Menu 2 found my network with "10AC012", leading 0 is skipped. The ID 0x010ac012 is correct, I see it in all my scanned messages. But what should I give as ID in Menu 3. I mean the format, the hex string with or without 0x? I tried different things, but it seems prog can not leave the first while loop in MenuAttachNetwork independent I give enter or push the send Button.
Thanks again,
Dietmar
Rodemfr
Member
You are right, your network id is 0x010ac012. This is hexadecimal number. To print it, I use Serial.print function which strips leading 0's.
For menu 3, that's a home made function which doesn't expect the "0x" prefi. You just need to enter the number as displayed by menu 2 : 10ac012. letters can be upper or lower case.
Concerning, frequencies. I see in SmartRF Studio that XTAL source can be either 26 or 27 MHz. ELECHOUSE driver might be assuming a 26MHz XTAL, while the board actually has a 27MHz XTAL (yours or mine). That could explain frequency deviation beetween our two boards. I unfortunately don't have my board schematics.
For menu 3, that's a home made function which doesn't expect the "0x" prefi. You just need to enter the number as displayed by menu 2 : 10ac012. letters can be upper or lower case.
Concerning, frequencies. I see in SmartRF Studio that XTAL source can be either 26 or 27 MHz. ELECHOUSE driver might be assuming a 26MHz XTAL, while the board actually has a 27MHz XTAL (yours or mine). That could explain frequency deviation beetween our two boards. I unfortunately don't have my board schematics.
Booster
New member
The Serial Monitor of Arduino IDE has problems to recognize CR. So I am using "*" as a delimiter for the HEX string as a workaround.
Frequency issue is easy to solve - only by tweaking the line
gRfReceiver.setMHZ(869.835 - 0.071);
But now I am back with eeprom settings. You are sure that your last commit is really working correct? At least the declaration of checksum is not correct. In my opinion uint8_t is not sufficient and follow in overflow. I would prefer uint16_t.
I can store the settings and verify. But after disconnect the module and reconnect the stored attachedNetwork is not available.
Frequency issue is easy to solve - only by tweaking the line
gRfReceiver.setMHZ(869.835 - 0.071);
But now I am back with eeprom settings. You are sure that your last commit is really working correct? At least the declaration of checksum is not correct. In my opinion uint8_t is not sufficient and follow in overflow. I would prefer uint16_t.
I can store the settings and verify. But after disconnect the module and reconnect the stored attachedNetwork is not available.
Rodemfr
Member
Usage of uint8_t is a choice. It likely overflows but this is not a problem. It is enough to detect a single bit change in the configuration area. I did not test extensively my latest commit but it was working normally the few times I tested it. It might be because the eeprom was already valid before I changed to the single byte access. Tonight, I will make a test after erasing EEPROM to verify the new writing method is OK.
Booster
New member
I reworked now my Configuration.cpp based on Preferences.h. It seems to work now: Menu started with NMEA conversion because networkID is gotten from emulated eeprom.
The Serial Monitor of Ubuntu's Arduino IDE is annoying. Also ESC key is not accepted. I use 'S' to stop conversion. Which console you are using? And which OS? Perhaps I make experiments with other programms.
The Serial Monitor of Ubuntu's Arduino IDE is annoying. Also ESC key is not accepted. I use 'S' to stop conversion. Which console you are using? And which OS? Perhaps I make experiments with other programms.
Rodemfr
Member
I use TeraTerm on Windows.
Booster
New member
Thank you. I am now using putty for linux. CR and ESC is accepted - no code change needed.
One question: In the time I am waiting for the U-blox module I would like to check transmitting capabilities. Make it sense to introduce a fixed data set for the GNSS data only for testing? E.g. substitute the while loop in GNSS_CALLBACK() around line 205 with a periodic loop transmitting the gNavData. Or do you have an better idea? Don't know if it will synchronize with the display requests.
One question: In the time I am waiting for the U-blox module I would like to check transmitting capabilities. Make it sense to introduce a fixed data set for the GNSS data only for testing? E.g. substitute the while loop in GNSS_CALLBACK() around line 205 with a periodic loop transmitting the gNavData. Or do you have an better idea? Don't know if it will synchronize with the display requests.
