observations with hardware modification u-blox and ls303dlhc

[dwarning]

I used the code, compiled with Arduino from branch gnss_compass together mn 100-2 display as a master, hull transducer for temp, speed and depth. In short form following remarks:

• Switch on sequence a bit annoying. Seems display must switched on first.
• Bug or feature? The esp converter can wake up display from sleep. Never seen in the display manual. But stops immediately with not valid network.
• Using the long messages (verbose mode) in monitor follows in core dumps and rebooting. With info mode everything is OK in long term. No reboots.
• The signal strength in health/type8 fluctuate between 0 and 8 in second tact. Value 8 is reasonable and can changed by cc1101 pa setting.

[mnsnoop]

• What order the devices are turned on shouldn't matter.
• Micronet devices waking each other up (and shutting each other down) is a feature. Do you get no valid network then it finds the network or no valid network then the display turns off? First one is a timing issue second one could be a lot of things.
• Setting verbose doesn't crash for me. You can use the Exception Stack Trace Decoder (https://github.com/me-no-dev/EspExceptionDecoder) to figure out which print it is.
• Same here. Never looked into it because the displays still see the data packets it rates as 0. There's probably something more to the protocol.

[dwarning]

Thanks.
I will check with the exception debug tool and come back. But I see you made another task to core distribution. Perhaps it is different now.

I am sure the real programmer (I am not!) will laughing about that:

anemometer.cpp line 110: string to long for 3 bytes.

micronet.cpp line 39, 40: memset of complex structure for init will be complained by gcc >8.0, {} of structure members in micronet.h sufficient? Or other method available.
line 91: iPredictedWindow no type here (int) - but it worked without!
line 477: default case wanted by higher gcc version

nmea2kbridge.cpp, WaypointList has a lot of unused variables.

printbuffer.h:
move "static const char *_cLogLevel[]" into cpp file, got an error if header was used by other files.
got an error with esp-idf because for all printXXX functions the char *format was not const

radio.cpp:
line 66 ff: no default for variable b
line 433: PIN_OP never used, can removed fro radio.h too
line 568: the Calibrate code can not work for cc1101 because pins have other names. I used #ifdef CC1000 macro to bail out.

[dwarning]

Attached the exception analysis. On top of the file the Serial output - later the dbug output. Seems not in your code. It happens only in verbose mode.

Exception_analysis.txt

[mnsnoop]

Attached the exception analysis. On top of the file the Serial output - later the dbug output. Seems not in your code. It happens only in verbose mode.

That's a stack canary exception. No idea what it could want to print that's so large but you'll soon find out. To fix this increase the stack size for the printer task. In printbuffer.cpp line 16:
-xTaskCreatePinnedToCore(tfPrint, "printer", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, &tPrinter, 0);
+xTaskCreatePinnedToCore(tfPrint, "printer", configMINIMAL_STACK_SIZE + 500, NULL, tskIDLE_PRIORITY, &tPrinter, 0);

anemometer.cpp line 110: string to long for 3 bytes.

cDir isn't a long. It's a 3 byte character array defined on line 104 (char cDir[3];).

micronet.cpp line 39, 40: memset of complex structure for init will be complained by gcc >8.0, {} of structure members in micronet.h sufficient? Or other method available.

Have no idea what's wrong with using memset to zero out a struct. That's it's purpose.

line 91: iPredictedWindow no type here (int) - but it worked without!

Compilers don't see returns. It reads the line like this:
int iPacketTime = 0, iPredictedWindow = 0;

line 477: default case wanted by higher gcc version

I don't see a point in adding a default case that did nothing besides code bloat.

nmea2kbridge.cpp, WaypointList has a lot of unused variables.

The NMEA waypoint list is a very complex message that I had to write a phraser for. To check it was working correctly I had to print out each part. It would be added work to rewrite the function without those variables and make future debugging harder.

move "static const char *_cLogLevel[]" into cpp file, got an error if header was used by other files.

I'd have to see the error.

got an error with esp-idf because for all printXXX functions the char *format was not const

You can probably make them all consts.

line 66 ff: no default for variable b

It doesn't need a default value and setting one would just waste clock cycles.

line 433: PIN_OP never used, can removed fro radio.h too

You can remove it. It was for debugging radio communication with an oscilloscope.

line 568: the Calibrate code can not work for cc1101 because pins have other names. I used #ifdef CC1000 macro to bail out.

It isn't for the cc1101 and as such isn't called when the radio is set to cc1101. Look in the Radio::Initialize() function;
434: #ifdef CC1000
...
476: Calibrate(); <-- only place it's called.
477: #endif
479: #ifdef CC1101
...

[dwarning]

Am 17.05.22 um 17:07 schrieb mnsnoop:

Attached the exception analysis. On top of the file the Serial output - later the dbug output. Seems not in your code. It happens only in verbose mode. That's a stack canary exception. No idea what it could want to print that's so large but you'll soon find out. To fix this increase the stack size for the printer task. In printbuffer.cpp line 16: -xTaskCreatePinnedToCore(tfPrint, "printer", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, &tPrinter, 0); +xTaskCreatePinnedToCore(tfPrint, "printer", configMINIMAL_STACK_SIZE + 500, NULL, tskIDLE_PRIORITY, &tPrinter, 0);

Yes, the exceptions disappear with larger stack. But it is still unstable with long messages. Have to analyze more.

anemometer.cpp line 110: string to long for 3 bytes. cDir isn't a long. It's a 3 byte character array defined on line 104 (char cDir[3];).

No it is not long. But see you want write "SW " into 3 byte. The space after SW is to much, no place for 0!

line 91: iPredictedWindow no type here (int) - but it worked without! Compilers don't see returns. It reads the line like this: int iPacketTime = 0, iPredictedWindow = 0;

Oh, sorry I overlooked the comma. Everything OK here.

line 66 ff: no default for variable b It doesn't need a default value and setting one would just waste clock cycles.

But in can happen that the following switch has no valid case - then b is not set. Better to have a default case with b=0? I am now experimenting with radio on core 1. But so far no luck, it is unstable. Did not understood the approach introduced in the loop. Did that mean that any 10 min we have an restart?

…

— Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMWNTGY6QEOMMNYAU7PMCDVKOY37ANCNFSM5WBQPJFA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[mnsnoop]

No it is not long. But see you want write "SW " into 3 byte. The space after SW is to much, no place for 0!

It's a character array, not a string. They don't need null termination.

But in can happen that the following switch has no valid case - then b is not set. Better to have a default case with b=0?

rRadio->eOutputState can only be OS_START_PADDING_BYTE, OS_PREAMBLE, OS_SYNCWORD, OS_DATA, or OS_END_PADDING_BYTE all of which are handled by the switch.

Did not understood the approach introduced in the loop. Did that mean that any 10 min we have an restart?

It causes a controlled reboot every 10 minutes. Easiest way to ensure esp32Micronet can run forever.

[dwarning]

Last experience on a 4h boat tour was OK, but there few breaks in communication over 2-5 min. Transmission comes back alone.
To tackle that I tried to generate oscillograms and decodes from SPI to cc1101 module without success. I have same connection as all my other hardware setups where I could catch anything with my scope:
#define PIN_MISO 19 #define PIN_MOSI 23 #define PIN_SCLK 18 #define PIN_CS 5 #define PIN_G0 2
I trigger to chip select but can find only few bytes and not the message which I can see with sdr stick at same time. Also display shows correct values.
Can you give me a hint how I can proceed.

[mnsnoop]

The message is transferred by synchronous serial at transmission baud on pin G0. The CC1101 provides the clock on pin MISO.

[dwarning]

Yes, now understood your approach, application note AN095 helped very much. I am able to decode on scope too.
I made very few changes in rf config. I think IF can be lowered because adc's dc component is filtered (in cost of 2-3 mA!). IF of 208kHz will give roughly 2dB gain. But not so important.
AN095 suggested switch on bit sync if packet mode is off. Your opinion?
The only problem I have is the non-secure startup procedure. If I switch on display at first and the converter connection appears after 30 - 60 seconds. Stable work - no breaks over hours. Except radio is pinned to core 0, but this is another problem.
Vice versus - converter first the display, connection will never established. Perhaps you can take a look in the logs from serial:
converter_on_display_later.log
display_on_converter_later.log
The attached screendump show 2 communications when connection works:

Any idea how I can tackle the startup problem? By scope, sdr stick and special logs?
I am off next 3 weeks and will come back after.
Thanks!

[mnsnoop]

AN095 suggested switch on bit sync if packet mode is off. Your opinion?

You can experiment with it but I found it did nothing. The crystals in NM gear did't drift enough over these short messages to go out of sync. At least not on any of the gear I had.

Vice versus - converter first the display, connection will never established. Perhaps you can take a look in the logs from serial

You've found a bug alright. I don't use network choice mode so didn't run into this issue. Your esp is starting a network and giving itself a 0 length window. When it wants to send data and needs a bigger window so it sends out 0x05 packets requesting one but we don't receive our own packets so it never gets the larger slot.

I've uploaded a fix. Let me know if it works.

Except radio is pinned to core 0

That shouldn't be possible as radio gets pinned to core 1 on line 212 of radio.cpp.

[mnsnoop]

I have no idea if the first window can support sending data or not. You'll have to test it as I no longer have my Micronet gear. If it doesn't work we can try giving ourselves a second slot to transmit data in.

[dwarning]

Thank you very much, I will check it in about 3 weeks and come back.

…

Am 01.06.2022 um 04:28 schrieb mnsnoop ***@***.***>:  I have no idea if the first window can support sending data or not. You'll have to test it as I no longer have my Micronet gear. If it doesn't work we can try giving ourselves a second slot to transmit data in. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.