Micronet network not detected with Teensy 4.0

[tvr256]

Since the commit to reduce SPI delays ( #48 ) , the Micronet network is no longer detected on my system. Rolling back to the previous commit fixes the issue.

I'm running a Teensy 4.0, my configuration (and the error) are identical to what @j-lang described here : #11

[frgaude]

Maybe a frequency calibration is needed

…

On Wed, 16 Nov 2022, 13:45 tvr256 ***@***.***> wrote: Since the commit to reduce SPI delays ( #48 <#48> ) , the Micronet network is no longer detected. I'm running a Teensy 4.0, identical configuration to j-lang here : #11 <#11> — Reply to this email directly, view it on GitHub <#53>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APUEFX2U3YQORMI5SNGYGP3WITJN5ANCNFSM6AAAAAASCGCFGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tvr256]

I tried a calibration, but no network was detected ( terminal displayed ........................ instead of ........******......... )

[dwarning]

@tvr256 : Can you give the git SHA1 ID from where the failure appears.

[tvr256]

c4c9692 works perfectly
0dc28f4 (and anything newer) fails

[dwarning]

Can you set currentOffset in Calibrate (CC1101Driver.cpp line 422) to a value of 24 instead 0 and try again. Am 16.11.22 um 14:03 schrieb tvr256:

…

c4c9692 <c4c9692> works perfectly 0dc28f4 <0dc28f4> (and anything newer) fails — Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMWNTELTOIPQ2AZHQPQOELWITLSZANCNFSM6AAAAAASCGCFGU>. You are receiving this because you commented.Message ID: ***@***.***>

[tvr256]

I assume you mean currentFreqOff on line 422? I tried changing it to 24 but unfortunately it hasn't helped.

Scanning Micronet networks for 5 seconds ... done

/!\ No Micronet network found /!\
Check that your Micronet network is powered on.

[Rodemfr]

It seems the new faster SPI timings are too fast for CC1101. Are you flashing MicronetToNMEA with a CPU frequency of 600MHz or 24MHz ?
Can you test a last modification before I revert the change :
In CC1101Driver.cpp, replace ChipDeselect(0); by ChipDeselect(1); everywhere you see it.
Thanks.

[tvr256]

I'm flashing to a Teensy 4.0. I believe the default frequency is 600MHz, I'm not sure how to change it?

I replaced all 4 instances of ChipDeselect(0); with ChipDeselect(1); but it still doesn't detect the network.

[tvr256]

It seems the new faster SPI timings are too fast for CC1101. Are you flashing MicronetToNMEA with a CPU frequency of 600MHz or 24MHz ?

Found it! If I change CPU frequency to 24MHz, it works perfectly with ChipDeselect(0);. Change back to 600MHz and the network isn't detected.

[Rodemfr]

Can you try to set the CPU at 600MHz and to use ChipDeselect(1) instead at ChipDeselect(0) ? That would help me to know if the fix is OK.

[tvr256]

Can you try to set the CPU at 600MHz and to use ChipDeselect(1) instead at ChipDeselect(0) ? That would help me to know if the fix is OK.

I already tried that (see comment above) but sadly it didn't work.

[Rodemfr]

Sorry, I missed it. So, I will roll back the SPI speed-up. It is not stable enough.
Thanks for testing and reporting the issue.

[Rodemfr]

I pushed a fix in branch fix_issue_53. This fix does not revert all the timing optimizations to try to keep the most interesting ones. Could you test it at 600MHz ?
After having totally fixed this issue, I advise you to flash Teensy 4.0 at 24MHz. It will work fine and the power consumption will significantly decrease (almost half the power on my system).

[tvr256]

I pushed a fix in branch fix_issue_53. This fix does not revert all the timing optimizations to try to keep the most interesting ones. Could you test it at 600MHz ? After having totally fixed this issue, I advise you to flash Teensy 4.0 at 24MHz. It will work fine and the power consumption will significantly decrease (almost half the power on my system).

I've tested very quickly and it seems to be working well! I'll do some more testing as soon as I'm free.

[dwarning]

I want only confirm that the actual master branch is working for me with T3.6 and T4.1.
It is pitty that we haven't the old approach to debug frequency issues by sending simple messages and catch them by rtlsdr stick. That we have had in the past.

[Rodemfr]

I fear rtl-sdr would not help here. The issue is related to the timing between CS High and CS Low on SPI. What is new to me is that the timing optimization was working for you and for me, but not for tvr256' CC1101. It shows that we have disparities in the behavior of CC1101. We might have different versions of CC1101 on the market.

[dwarning]

OK. Two questions: What was your criteria for the different choices for the CS delay time to the different SPI commands?
And can I help by scope the signals? Can you describe a test scenario?
BTW, I found a small anomaly and will open another issue. Not sure if it has to do with the issue #53.

[tvr256]

I pushed a fix in branch fix_issue_53. This fix does not revert all the timing optimizations to try to keep the most interesting ones. Could you test it at 600MHz ? After having totally fixed this issue, I advise you to flash Teensy 4.0 at 24MHz. It will work fine and the power consumption will significantly decrease (almost half the power on my system).

I've tested very quickly and it seems to be working well! I'll do some more testing as soon as I'm free.

I've tested again this morning, and I can confirm the following:

Latest Head 3b761a7 : 600MHz fails, 24MHz works
Latest head, with ChipDeselect(1) : 600MHz fails, 24MHz works
Branch fix_issue_53 : 600MHz and 24MHz both work

[Rodemfr]

Thanks ! I will merge the branch in master.

@dwarning : To test, I run Sailaway sail simulator with OpenCPN on my PC which I connect to my MTN setup through Bluetooth (HC-06). MTN is configured to receive all data from HC-06 NMEA except magnetic heading and GNSS Data which are received from LSM303 & NEO-8M. I then just check that my displays can run a few hours.
For this issue, it seems that it is the timings behind Spi Strobe commands of CC1101 which are problematic. Reading the datasheet §10.4, I see that the driver should wait MISO line to go low before addressing a new command. This is not exactly what is done in the driver today since we are waiting for MOSI to go low at the beginning of the next SPI command. This might be the cause of the problem.