I only checked the pyshical pin connection by eye. I dont have any tools to monitor the pins but I will have a search and see what I can learn!!
I have also changed my Pi 4 but still no good, I think I will purchase another dragino.
I only checked the pyshical pin connection by eye. I dont have any tools to monitor the pins but I will have a search and see what I can learn!!
I have also changed my Pi 4 but still no good, I think I will purchase another dragino.
@mauriceatkinson - if you can, check the version of the dragino lora/gps hat. On the board there is often a version / revision number. As v1.0 differs significantly to the V1.4’s
To the extent, you need to physically install connections between pins on V1.0 thru 1.2/1.3 (need to check) but they are pre-done on the V1.4 boards.
Those links are for DIO signals required by LMIC.
I think we have established that he has an SPI problem because the code attempts to set the sx1276 mode but an immediate read back returns zero. In rx_chain_calibration() this causes the code to attempt to set an invalid mode which causes an exception.
However, @mauriceatkinson did say it was previously working on Buster. The problem,apparently, only appeared after trying to get it working on Bullseye. I have it working on Bullseye having switched from Buster several months ago.
@bnnorman I have received the new dragino board and back up and running again on Buster. Thanks for your assistance
So, hardware fault - unlucky. However, I would attempt to find out if it’s just the connectors since they are most likely to fail. Visual inspection isn’t always enough.
@bnnorman I am looking to use my lorawan sensors in Thailand which uses the AS923-925 frequency. Are you aware of anybody looking to implement this frequency into your code? Plus a dumb question; what is the difficulty level in adding this frequency into the code?
@bnnorman Just to let you know I sucessfully used your code to access my newly built Chirpstack server. I needed to change TTN devaddr within the dragino.py to satisfy Chirpstack join requests but apart from that it all looks good. Cheers
Excellent and Interesting. Were you using ABP or OTAA? Can you explain in more detail? May be worth adding to the readme for others, and me, since I don’t know the chirpstack server (I know of it).
AFAIK the devaddr is sent back from the server when the end device joins so I’m very curious as to what was changed.
Thanks for letting me know.
I am using the dragino lora/gps hat using OTAA to a self hosted Chirpstack server (I have installed the Chirpstack network and application server on the same machine). My initial testing has shown that there are no issues and data is being delivered to my Home Assistant/Grafana via mqtt without errors being reported or seen.
The only change to your dragino software was # TTN devaddr always starts 0x26 or 0x27, Chirpstack starts with 0x0, (Rak Wireless 7268 begins with 0x2) if devaddr[0] != 0x0 and devaddr[0] !=0x96: #if devaddr[0] != 0x2 and devaddr[0] != 0x69: #if devaddr[0] !=0x26 and devaddr[0] != 0x27: self.logger.debug(f"Invalid TTN devaddr {devaddr}, should begin with 0x26 or 0x27") return False
I have also tested your software using a Rak Wireless 7268 gateway configured as a network server (this means I dont need either TTN or Chirpstack) and this worked making the relevent change above.
At the moment I see the only benefit of using TTN is their support for end nodes and the ease of installing and support of inbuilt payload decoders. However I may be missing something.
That’s great. Thanks.
Missing something ?
TTN provide a free to use forum that is specifically for the discussion of TTN projects.
The benefit from TTN (apart from being able to get help on the forum and at local communities) is the network coverage you get for free at countless locations. That might not matter if you deploy in and around your home only, but when you deploy in your car, at an allotment, at your parents or at a friend etc etc you might not have to deploy a gateway as well.
And by using TTN and connecting your gateways to it you help others find coverage without having to invest in and deploy a gateway themselves. (Which at home might be simple but elsewhere can be quite a challenge)
Many do! To add to the comments from @kersing @LoRaTracker and the support you’ve seen from @bnnorman and given I suspect you may (also) be a Brit or atleast in the UK(*), I would also point you to the TTN UK Community page… maybe you find a source of encouragement there…
https://www.thethingsnetwork.org/country/united-kingdom/
104 communities, typically 830-930 live gateways at any time…plus others connected through PacketBroker from several Local/County Councils or private enterprise…
(*) despite the Thai ref & freq?
This community that you are using to further your technical expertise for a start.
And the gateway coverage.
And the hosted stack that runs & is supported 24/7.
But overall, I believe you are mostly missing any sense of etiquette.
thanks to those who pointed out the benefits of TTN, but to those who get personal…
@mauriceatkinson I just received an email from you but when I ‘Visit Topic’ I find the post deleted! Very confusing!
Have you fixed the problem?
It has been many months since I last did any development on this code.
I’ve put the post back so your good to go.
@descartes Thanks, that was the email I received.
@mauriceatkinson Looks like a corruption in the config file at char 2288 to me.
@bnnorman sorry to reopen this thread but I am pulling my hair out trying to get my sensor working again on TTN.
The running test.py shows “waiting for join accept”.
TTN console shows the end device is seen and receiving messages.
In the live data tab I see “accept join request” message and “forward join-accept message”
The test.log shows the following errors
2023-02-26 16:51:22,454 - registered - 564 - DEBUG - devaddr not assigned
2023-02-26 16:51:24,456 - registered - 550 - INFO - checking if already registered.
2023-02-26 16:51:24,457 - registered - 556 - INFO - devaddr [0, 0, 0, 0] len 4.
2023-02-26 16:51:24,457 - registered - 564 - DEBUG - devaddr not assigned
I have reinstalled everything from scratch and I get back to this same issue all the time. I am obviously doing something wrong but for the life of my I cannot work out what.
Any pointers very much appreciated
How close are gw & node? What rssi values are you seeing?