No Lora sending

[xpix]

hello, Dave,

I'm having huge problems getting my payload up and running and I'm about to give up. After testing on several Raspberry with different Rasbpians, here is a short description of my problem:

System: RPI2 / raspbian

Gatway works fine, RSSI is displayed and it also tries to retune itself when I send something with another RPI ( another lora test program ).

Now I start the tracker on the same machine with the same LoRa module, then it tries to send one hundred telemetry data in one second. From my experience I know that this can't be because it takes about 1 second in mode=1 for a message.

So Gatway works on the same RPI, but the "tracker" does not... i am really at a loss, but i would like to use your software, because i have had very good experiences with it.

I got it to run last year, unfortunately I didn't document it and I can darkly remember that maybe a modprobe for a module is missing.

I HOPE you can help, maybe it's a good idea to publish an extra RPI image where all settings have already been made?

Best regards Frank from germany :)

RASPBERRY PI-IN-THE-SKY FLIGHT COMPUTER
=======================================

RPi Hardware    : BCM2835
RPi Revision    : a02082
RPi Model A+ or B+ or B V2
PITS+ Board
HDMI/Composite outputs will be disabled
RTTY Disabled
Camera (None) Disabled
GPS Power Saving = OFF
Switching GPS to flight mode above 1000 metres
LORA0 - frequency set to 434.251
      - Payload ID = 'XSK4'
      - Mode 0 (Telemetry)
      - DIO0=6 DIO5=5
      - Using ASCII Transmissions
      - Power set to 88h
Powering off HDMI
I2C GPS using SDA = 2, SCL = 3
LoRa channel 0 DIO0=6 DIO5=5
Opened I2C GPS Port
Failed to open i2c port
Older board with SPI ADC
Disabling SPI ADC code as LoRa CE0 is enabled!!
LORA0: ID,Ctr,Time,Lat,Lon,Alt,Sped,Head,Sats,Int.Temp
LORA0: $$XSK4,1,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*7F93
LORA0: $$XSK4,2,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*C00D
LORA0: $$XSK4,3,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*AA87
LORA0: $$XSK4,4,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*AF10
LORA0: $$XSK4,5,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*C59A
LORA0: $$XSK4,6,00:00:00,0.00000,0.00000,00000,0,0,0,47.2*7A04

[xpix]

P.S: So i ordered now this lora module and hope this will work: https://store.uputronics.com/index.php?route=product/product&path=61&product_id=99

[daveake]

Frank,

I've ordered one of these Dragino boards for test.  Looking at the schematic it should only need DIO0=4 passed to the LoRa module init routine (the DIO0 pin on the LoRa module connects to BCM pin 4); I don't know if you tried that but that's all it should need for Pytrack to work.

I'll look at supporting the GPS on that board.  Be aware that this particular module is not guaranteed to work at all HAB altitudes.  Adafruit use it on their "Ultimate" GPS board and specifically state that it is not recommended for HAB and that they have only tested it to 40km using a GPS simulator.  40km is enough for most but not all HAB flights.

Dave

On 13/08/2018 09:14, Frank Herrmann wrote:

hello, Dave,

I'm having huge problems getting my payload up and running and I'm about to give up. After testing on several Raspberry with different Rasbpians, here is a short description of my problem:

System: RPI2 / raspbian

Gatway works fine, RSSI is displayed and it also tries to retune itself when I send something with another RPI ( another lora test program ).

Now I start the tracker on the /same/ machine with the same LoRa module, then it tries to send one hundred telemetry data in one second. From my experience I know that this can't be because it takes about 1 second in mode=1 for a message.

So Gatway works on the same RPI, but the "tracker" does not... i am really at a loss, but i would like to use your software, because i have had very good experiences with it.

I got it to run last year, unfortunately I didn't document it and I can darkly remember that maybe a modprobe for a module is missing.

I HOPE you can help, maybe it's a good idea to publish an extra RPI image where all settings have already been made?

Best regards Frank from germany :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PiInTheSky/pits/issues/31, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBodGr6ftkRsGDEVbIwgD1XZBvN9dB0ks5uQTVRgaJpZM4V6EOF.

[xpix]

Maybe I should explain my frustration briefly, I tried both versions of the tracker. pits and pytrack, with the pits tracker the problem with DIO5 appeared again and again.

Please don't laugh, but I now have a combination running with pytrack and the lora-gateway. I'm trying to get skygate up and running now. But I'll writing an article about the skygate github.

So, in my opinion you should definitely do without DIO5, because this pin is simply not used on most LoRa boards and therefore has no contact. Also there should be an example of a client/server program where you can quickly test if the setup is correct and if data can be received. For beginners it is certainly difficult to find the right MHz number. I had specified e.g. 434.451 and ended up at 434.434 :)

For example, when I use lora modules from different manufacturers, I noticed that they do not always work together.

[daveake]

Re the "not working together", that's just the frequency deviation that every module has from the nominal frequency. It can be +/- 5kHz from what the software sets, so 2 mofules can be up to 10kHz apart from each other. For the usual HAB bandwidth setting of 20.8kHz, the difference between modules needs to be no more than 4kHz, so it's entirely possible for packets not to pass (typically the receiver will report a CRC error).

This is a hardware limitation with inexpensive LoRa modules.

On 14 August 2018 at 10:05, Frank Herrmann notifications@github.com wrote:

Maybe I should explain my frustration briefly, I tried both versions of the tracker. pits and pytrack, with the pits tracker the problem with DIO5 appeared again and again.

Please don't laugh, but I now have a combination running with pytrack and the lora-gateway. I'm trying to get skygate up and running now. But I'll writing an article about the skygate github.

So, in my opinion you should definitely do without DIO5, because this pin is simply not used on most LoRa boards and therefore has no contact. Also there should be an example of a client/server program where you can quickly test if the setup is correct and if data can be received. For beginners it is certainly difficult to find the right MHz number. I had specified e.g. 434.451 and ended up at 434.434 :)

For example, when I use lora modules from different manufacturers, I noticed that they do not always work together.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PiInTheSky/pits/issues/31#issuecomment-412805390, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBodHNOpmxxTNWJnrrHo4xMbO-edDYMks5uQpLRgaJpZM4V6EOF .

[daveake]

Re DIO5: I've removed the use of this in PyTrack - new version pushed today. I've also allowed it to be ignored in PITS by setting DIO5 to zero in the config. I'll push that soon.

I've also added support for the Dragino GPS/LoRa HAT, to PITS. I have no plans to add it to Pytrack.

Please note that both programs were written specifically for the PITS hardware and LoRa board. That's the only hardware we routinely test and fly with.

Dave

On 14 August 2018 at 10:21, David Akerman dave@sccs.co.uk wrote:

Re the "not working together", that's just the frequency deviation that every module has from the nominal frequency. It can be +/- 5kHz from what the software sets, so 2 mofules can be up to 10kHz apart from each other. For the usual HAB bandwidth setting of 20.8kHz, the difference between modules needs to be no more than 4kHz, so it's entirely possible for packets not to pass (typically the receiver will report a CRC error).

This is a hardware limitation with inexpensive LoRa modules.

On 14 August 2018 at 10:05, Frank Herrmann notifications@github.com wrote:

Maybe I should explain my frustration briefly, I tried both versions of the tracker. pits and pytrack, with the pits tracker the problem with DIO5 appeared again and again.

Please don't laugh, but I now have a combination running with pytrack and the lora-gateway. I'm trying to get skygate up and running now. But I'll writing an article about the skygate github.

So, in my opinion you should definitely do without DIO5, because this pin is simply not used on most LoRa boards and therefore has no contact. Also there should be an example of a client/server program where you can quickly test if the setup is correct and if data can be received. For beginners it is certainly difficult to find the right MHz number. I had specified e.g. 434.451 and ended up at 434.434 :)

For example, when I use lora modules from different manufacturers, I noticed that they do not always work together.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PiInTheSky/pits/issues/31#issuecomment-412805390, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBodHNOpmxxTNWJnrrHo4xMbO-edDYMks5uQpLRgaJpZM4V6EOF .

[xpix]

Very nice, now it works for me as designed. Many thanks, i'm really happy about it!