Code Monkey home page Code Monkey logo

Comments (17)

jgromes avatar jgromes commented on June 10, 2024 3

So despite that promising lead described above, I was not able to replicate this with a DRF1262G, the module seems to have no issue calibrating and setting the frequency to 869.525024 MHz:

CMDW    98
SI              D8      DB
SO      A2      A2      A2
CMDW    86
SI              36      58      66      80
SO      A2      A2      A2      A2      A2

So ... hardware issue it is :)

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024 1

Given the -707 error and the custom config, I'm 99% certain this is a hardware/crystal issue, not a problem with the library, especially not the LW stack. Maybe @jgromes can suggest something, and I'd suggest converting this to a discussion.

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024 1

I plan on swapping to a different model in future but the tests were done on the same board. The latest dump with lora v1.1 were all OTAA, however.

Ah, thanks for the heads up, will add in a button and test on button press instead.

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024 1

Tested on the new devboard, also with sx1262 and TCXO. Settings are a bit different but I do not recieve the same error and the connection is stable. @StevenCellist I think you are correct and we can put this down as a hardware issue.

Thanks again for the support!

from radiolib.

jgromes avatar jgromes commented on June 10, 2024 1

A bit late, but here's what I think is actually going on.

The -707 error happens when attempting to change frequency to 869.525024 MHz. This also triggers image rejection calibration. This calibration actually fails, though for some reason this is not caught by the library, hence why it errors during the next SPI transfer.

So, why is this calibration failing, and why don't the previous calibrations fail? Checking previous calibration comands (CMDW 98 in the log), all those that pass have arguments 0xD7, 0xDB. But the ones that fail have 0xD8, 0xDB. These arguments specify the frequency range in which to perform the calibration, and are calculated from the frequency we want to set. The calculation is from LR1110 datasheet, the SX1262 datasheet does not actually specify it, it only has some commonly used bands. The equations for LR1110 yield the same numbers, and so I though it should be safe to use it. So perhaps there are some corner cases that need to be investigated ... or perhaps my assumption that the calibration is the same for LR1110 and SX126x doesn't really hold up. I'll see if I can replicate the issue without LoRaWAN stack.

As a SW developer, I too can be prone to blaming the HW, let's cut it some slack - at least for now ;)

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024

Well.. why not try to solve the DevNonce issue? This in turn will very likely solve the issue you find here: RadioLib is LoRaWAN v1.1 from the ground up! LoRaWAN v1.0.x is available as sort of a fallback but by no means guaranteed - which you currently found out. Maybe if I ever have a lot of spare time I will see if there are small bugs to be fixed to get 1.0.x running, but 1.1 is where it is at.

If you encounter a valid reason for 1.1 to fail working I will happily assist, but unfortunately for you I am not solving 1.0.x issues anywhere soon. BTW: don't just revert to an older version if it doesn't work, better dig in and make it work, because it can work!

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024

Oh, and also, please run RadioLib 6.4.2, 6.4.0 is actually borked w.r.t. LoRaWAN. Switching to 6.4.2 will likely also solve the issue you encountered!

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024

Thanks for your fast reply! Ok, will try to get 1.1 working first then :)

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024

Quick note that you're probably best off with also re-creating your device on TTN for a fresh set of keys, so that after switching to 6.4.2 the DevNonce counter will be at 0. Then as long as you don't change keys and do call node.saveSession() at appropriate interval (during development probably best after every up/downlink), you should be able to have an easy life. But there are some particularities - devil is in the detail.

from radiolib.

HeadBoffin avatar HeadBoffin commented on June 10, 2024

It looks like you are sort of mixing OTAA and ABP with the same DevEUI and it's not totally clear if you are joining and then refreshing to use ABP but it's pulling the session from NVM. I'm not sure we've tested that combo (that's polite for "no chance we coded that situation"). OTAA on v1.1 works on ESP32 devices. Everything else is unknown/unverified but there are reports that plain ABP works. So if you want to crack on with making a device, I'd stick to OTAA on v1.1. If you want to join the testing fray, that would be cool. But with separate setups on the LNS for the two modes. And ABP will need the f_cnt resets setting for Dev mode.

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024

It looks like you are sort of mixing OTAA and ABP with the same DevEUI and it's not totally clear if you are joining and then refreshing to use ABP but it's pulling the session from NVM. I'm not sure we've tested that combo (that's polite for "no chance we coded that situation"). OTAA on v1.1 works on ESP32 devices. Everything else is unknown/unverified but there are reports that plain ABP works. So if you want to crack on with making a device, I'd stick to OTAA on v1.1. If you want to join the testing fray, that would be cool. But with separate setups on the LNS for the two modes. And ABP will need the f_cnt resets setting for Dev mode.

I apologise for the ambiguous code. The device EUI is random as I dont want sensitve info in public, I merely copied it for the APB. My intention was also not to have the device act as both APB or OTAA but simply have a quick setup where I could though in the keys, select a mode and test it.

I managed to get OTAA v1.1 working on TTN now, will test further. Just to be sure, I added node.saveSession() after each uplink/downlink and on startup a node.restore() after the node is started. The connection seems a bit unstable as I keep recieving -707 errors which then lead to -1108 error code when trying to send the message. Here is a snippet of the debug log

(16:00:38.682) Channel frequency UL = 868.299988 MHz

(16:00:38.682) CMDW	98	

(16:00:38.682) SI	D7	DB	

(16:00:38.755) SO	A2	A2	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDW	86	

(16:00:38.755) SI	36	44	CC	C0	

(16:00:38.755) SO	A2	A2	A2	A2	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) DR 24: LORA (SF: 7, BW: 125.000000, CR: 5)

(16:00:38.755) CMDR	11	

(16:00:38.755) SI	0	0	

(16:00:38.755) SO	A2	1	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDR	11	

(16:00:38.755) SI	0	0	

(16:00:38.755) SO	A2	1	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDW	8B	

(16:00:38.755) SI	7	4	3	0	

(16:00:38.755) SO	A2	A2	A2	A2	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDR	11	

(16:00:38.755) SI	0	0	

(16:00:38.755) SO	A2	1	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDW	8B	

(16:00:38.755) SI	7	4	3	0	

(16:00:38.755) SO	A2	A2	A2	A2	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDR	11	

(16:00:38.755) SI	0	0	

(16:00:38.755) SO	A2	1	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) CMDW	8B	

(16:00:38.755) SI	7	4	1	0	

(16:00:38.755) SO	A2	A2	A2	A2	

(16:00:38.755) CMDR	C0	

(16:00:38.755) SI	0	

(16:00:38.755) SO	22	

(16:00:38.755) uplinkMsg pre-MIC:

(16:00:38.755) 0000000 c0 00 78 56 08 8c fb 3f 13 00 00 00 34 12 ba ab | ..xV...?....4...

(16:00:38.755) 0000010 40 d5 ef 0b 26 80 07 00 0a a6 95 cb f4 0d 00 00 | @...&...........

(16:00:38.755) 0000020 14                                              | .                 

(16:00:38.755) uplinkMsg:

(16:00:38.755) 0000000 49 00 00 00 00 00 d5 ef 0b 26 07 00 00 00 00 0d | I........&......

(16:00:38.760) 0000010 40 d5 ef 0b 26 80 07 00 0a a6 95 cb f4 13 1e d6 | @...&...........

(16:00:38.765) 0000020 9a                                              | .                 

(16:00:38.774) CMDW	80	

(16:00:38.774) SI	0	

(16:00:38.774) SO	A2	

(16:00:38.774) CMDR	C0	

(16:00:38.777) SI	0	

(16:00:38.777) SO	22	

(16:00:38.777) CMDR	11	

(16:00:38.777) SI	0	0	

(16:00:38.777) SO	A2	1	

(16:00:38.777) CMDR	C0	

(16:00:38.777) SI	0	

(16:00:38.777) SO	22	

(16:00:38.782) CMDR	11	

(16:00:38.782) SI	0	0	

(16:00:38.782) SO	A2	1	

(16:00:38.782) CMDR	C0	

(16:00:38.782) SI	0	

(16:00:38.782) SO	22	

(16:00:38.782) Timeout in 77184 us

(16:00:38.788) CMDR	11	

(16:00:38.788) SI	0	0	

(16:00:38.788) SO	A2	1	

(16:00:38.788) CMDR	C0	

(16:00:38.788) SI	0	

(16:00:38.788) SO	22	

(16:00:38.788) CMDR	1D	7	36	

(16:00:38.794) SI	0	0	

(16:00:38.794) SO	A2	D	

(16:00:38.794) CMDR	C0	

(16:00:38.794) SI	0	

(16:00:38.794) SO	22	

(16:00:38.794) CMDW	D	7	36	

(16:00:38.794) SI	D	

(16:00:38.794) SO	A2	

(16:00:38.798) CMDW	8C	

(16:00:38.798) SI	0	8	0	11	1	0	

(16:00:38.798) SO	A2	A2	A2	A2	A2	A2	

(16:00:38.798) CMDR	C0	

(16:00:38.798) SI	0	

(16:00:38.804) SO	22	

(16:00:38.804) CMDW	8	

(16:00:38.804) SI	2	1	0	1	0	0	0	0	

(16:00:38.804) SO	A2	A2	A2	A2	A2	A2	A2	A2	

(16:00:38.810) CMDR	C0	

(16:00:38.810) SI	0	

(16:00:38.810) SO	22	

(16:00:38.810) CMDW	8F	

(16:00:38.810) SI	0	0	

(16:00:38.810) SO	A2	A2	

(16:00:38.810) CMDR	C0	

(16:00:38.810) SI	0	

(16:00:38.816) SO	22	

(16:00:38.816) CMDW	E	0	

(16:00:38.816) SI	40	D5	EF	B	26	80	7	0	A	A6	95	CB	F4	13	1E	D6	9A	

(16:00:38.821) SO	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	A2	

(16:00:38.821) CMDR	C0	

(16:00:38.827) SI	0	

(16:00:38.827) SO	22	

(16:00:38.827) CMDW	2	

(16:00:38.827) SI	43	FF	

(16:00:38.827) SO	A2	A2	

(16:00:38.827) CMDR	C0	

(16:00:38.827) SI	0	

(16:00:38.832) SO	22	

(16:00:38.832) CMDR	1D	8	89	

(16:00:38.832) SI	0	0	

(16:00:38.832) SO	A2	4	

(16:00:38.832) CMDR	C0	

(16:00:38.832) SI	0	

(16:00:38.832) SO	22	

(16:00:38.832) CMDR	11	

(16:00:38.837) SI	0	0	

(16:00:38.837) SO	A2	1	

(16:00:38.837) CMDR	C0	

(16:00:38.837) SI	0	

(16:00:38.837) SO	22	

(16:00:38.837) CMDW	D	8	89	

(16:00:38.837) SI	4	

(16:00:38.837) SO	A2	

(16:00:38.844) CMDW	83	

(16:00:38.844) SI	0	0	0	

(16:00:38.844) SO	A2	A2	A2	

(16:00:38.844) CMDR	C0	

(16:00:38.844) SI	0	

(16:00:38.844) SO	62	

(16:00:38.891) CMDW	2	

(16:00:38.891) SI	43	FF	

(16:00:38.891) SO	AC	AC	

(16:00:38.891) CMDR	C0	

(16:00:38.891) SI	0	

(16:00:38.891) SO	2C	

(16:00:38.891) CMDW	80	

(16:00:38.891) SI	0	

(16:00:38.956) SO	AC	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) Uplink sent <-- Rx Delay start

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) 

(16:00:38.956) Channel frequency DL = 868.299988 MHz

(16:00:38.956) CMDW	98	

(16:00:38.956) SI	D7	DB	

(16:00:38.956) SO	A2	A2	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDW	86	

(16:00:38.956) SI	36	44	CC	C0	

(16:00:38.956) SO	A2	A2	A2	A2	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) DR 24: LORA (SF: 7, BW: 125.000000, CR: 5)

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDW	8B	

(16:00:38.956) SI	7	4	1	0	

(16:00:38.956) SO	A2	A2	A2	A2	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDW	8B	

(16:00:38.956) SI	7	4	1	0	

(16:00:38.956) SO	A2	A2	A2	A2	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDW	8B	

(16:00:38.956) SI	7	4	1	0	

(16:00:38.956) SO	A2	A2	A2	A2	

(16:00:38.956) CMDR	C0	

(16:00:38.956) SI	0	

(16:00:38.956) SO	22	

(16:00:38.956) CMDR	11	

(16:00:38.956) SI	0	0	

(16:00:38.956) SO	A2	1	

(16:00:38.956) CMDR	C0	

(16:00:38.958) SI	0	

(16:00:38.958) SO	22	

(16:00:38.958) CMDR	1D	7	36	

(16:00:38.958) SI	0	0	

(16:00:38.958) SO	A2	D	

(16:00:38.958) CMDR	C0	

(16:00:38.958) SI	0	

(16:00:38.964) SO	22	

(16:00:38.964) CMDW	D	7	36	

(16:00:38.964) SI	9	

(16:00:38.964) SO	A2	

(16:00:38.964) CMDW	8C	

(16:00:38.964) SI	0	8	0	FF	1	1	

(16:00:38.964) SO	A2	A2	A2	A2	A2	A2	

(16:00:38.969) CMDR	C0	

(16:00:38.969) SI	0	

(16:00:38.969) SO	22	

(16:00:38.969) CMDR	11	

(16:00:38.969) SI	0	0	

(16:00:38.969) SO	A2	1	

(16:00:38.974) CMDR	C0	

(16:00:38.974) SI	0	

(16:00:38.974) SO	22	

(16:00:43.883) CMDW	8	

(16:00:43.883) SI	2	62	2	2	0	0	0	0	

(16:00:43.883) SO	A2	A2	A2	A2	A2	A2	A2	A2	

(16:00:43.883) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDW	8F	

(16:00:43.913) SI	0	0	

(16:00:43.913) SO	A2	A2	

(16:00:43.913) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDW	2	

(16:00:43.913) SI	43	FF	

(16:00:43.913) SO	A2	A2	

(16:00:43.913) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDR	11	

(16:00:43.913) SI	0	0	

(16:00:43.913) SO	A2	1	

(16:00:43.913) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDR	1D	7	36	

(16:00:43.913) SI	0	0	

(16:00:43.913) SO	A2	9	

(16:00:43.913) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDW	D	7	36	

(16:00:43.913) SI	9	

(16:00:43.913) SO	A2	

(16:00:43.913) CMDW	8C	

(16:00:43.913) SI	0	8	0	FF	1	1	

(16:00:43.913) SO	A2	A2	A2	A2	A2	A2	

(16:00:43.913) CMDR	C0	

(16:00:43.913) SI	0	

(16:00:43.913) SO	22	

(16:00:43.913) CMDW	82	

(16:00:43.949) SI	0	B	76	

(16:00:43.949) SO	A2	A2	A2	

(16:00:43.949) Opening Rx1 window (45856 us timeout)... <-- Rx Delay end 

(16:00:43.974) closing

(16:00:43.974) CMDR	12	

(16:00:43.974) SI	0	0	0	

(16:00:43.974) SO	A6	2	0	

(16:00:43.974) CMDW	80	

(16:00:43.974) SI	0	

(16:00:43.974) SO	A6	

(16:00:43.974) CMDW	98	

(16:00:43.974) SI	D8	DB	

(16:00:43.974) SO	A2	A2	

(16:00:43.974) CMDR	C0	

(16:00:43.974) SI	0	

(16:00:43.974) SO	2A	

(16:00:43.974) CMDW	86	

(16:00:43.974) SI	36	58	66	80	

(16:00:44.003) SO	AA	AA	AA	AA	

(16:00:44.003) failed, code -707

I will continue testing, but if you spot something or need more logs let me know.

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024

Given your custom XTAL configuration and the matching description which you can find, I'm not surprised.

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024

Yeah, the description helped me to fix the issue when it was just the LoRa chip not initialising correctly, hence the custom config, but now the chip does initialise, it gives a -707 when sending and recieving from the network.

I have tested it further, the module successfully sends an uplink to TTN after starting, the -707 comes after the initial message. So for my purpouses it will do as the device basically reboots after deep sleep. But if the sleep is replaced with a delay and the device remains powered on, it will eventually result in a -707 which will prevent any future messages from comming out.

I will dump some logs to try and provide assistance if it helps

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024

Logs

  1. V1.1 - Delay.log - Logs for the always on, delay for 60 seconds
  2. V1.1 - Deep sleep.log - Logs for the deep sleep for 60 seconds, reboot on wake

Notes:

  • Sometimes the -707 error does not occur after the initial uplink for the deep sleep logs, seems to be at random.
  • The sensor in question is a simple ultrasonic sensor that uses 2 digital pins, no interference detected

Let me know if I can help any further.

v1.1 - Deep sleep.log
v1.1 - Delay.log

from radiolib.

MPMcIntyre avatar MPMcIntyre commented on June 10, 2024

Cool! I do appreciate your input and effort. I will have another dev board to test on tomorrow, also with the sx1262. Hopefully that will resolve the issue, but I will keep you informed.

from radiolib.

HeadBoffin avatar HeadBoffin commented on June 10, 2024

Presumably the TCXO define is because you are swapping between boards, one with and one without? The WaveShare has TCXO so if you only have the one radio, perhaps remove the code that breaks it?

Or if you do have two radios, to make it easier to track down issues, any chance you can run to two separate code bases - or four even, depending on if you want ABP on both boards as well as OTAA?! Or have defines like BOARD_A_ON_OTAA, BOARD_A_ON_ABP etc

Couple of FYI's:

The device EUI is random as I dont want sensitve info in public,
It's sent in plain text during a join and appears in the logs of any gateway that hears it along with the JoinEUI. Only things ending in Key should be kept private.

And 60 seconds isn't within TTN Fair Use Policy

from radiolib.

StevenCellist avatar StevenCellist commented on June 10, 2024

Glad to hear, good luck on your adventures!

from radiolib.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.