search

mayeranalytics / pySX127x

This is a python interface to the Semtech SX127x, HopeRF RFM9x, Microchip RN2483 long range, low power transceiver families.
GNU Affero General Public License v3.0
171 stars 115 forks source link

AssertionError running lora_util.py #7

Closed jsonpoindexter closed 8 years ago

jsonpoindexter commented 8 years ago

Hi, I am receiving the following after following the 'Installation' section and running 'sudo ./lora_util.py'

/home/pi/projects/pySX127x/SX127x/board_config.py:51: RuntimeWarning: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings. GPIO.setup(BOARD.LED, GPIO.OUT) Traceback (most recent call last): File "./lora_util.py", line 35, in lora = LoRa(verbose=False) File "/home/pi/projects/pySX127x/SX127x/LoRa.py", line 92, in init self.rx_chain_calibration(968.) File "/home/pi/projects/pySX127x/SX127x/LoRa.py", line 835, in rx_chain_calibration self.set_freq(freq_bkup) File "/home/pi/projects/pySX127x/SX127x/LoRa.py", line 271, in set_freq assert self.mode == MODE.SLEEP or self.mode == MODE.STDBY or self.mode == MODE.FSK_STDBY AssertionError

I have followed the wiring table provided as well as connected the SPI pins from the RPI2 to the LoRa module.

I am running this on a Raspberry Pi 2 Model B with the latest RASPBIAN JESSIE and a InAir4 433Mhz LoRa module.

Could it have something to do with setting the freq to 868 in LoRa.py line 807 when I am using a 433Mhz?

Please let me know if can provide any more information.

Thanks

thomasverbeke commented 8 years ago

Reset your LoRa board or Raspberry Pi. I have seen this error many times and solved it by resetting my device.

dmahony commented 8 years ago

I had a similar issue when my wireless tranceiver wasnt soldered properly.

jsonpoindexter commented 8 years ago

@thomasverbeke to be clear, this can be done by power cycling the LoRa board or Raspberry Pi, correct?

@dmahony can you please explain in your case what was wrong with the soldering?

Thank you both for you input.

Also, just to add more info, here is my pin out according to http://i.stack.imgur.com/Ct2JG.png

inAir4 DIO0 >> GPIO 22(pin 15) inAir4 DIO1 >> GPIO 23(pin 16) inAir4 DIO2 >> GPIO 24(pin 18) inAir4 DIO3 >> GPIO 25(pin 22) inAir4 Reset>> NA LED >> GPIO 18(pin 12) inAir4 VS >> GPIO 04(pin 07) inAir4 3V3 >> 3.3v(pin 01) inAir4 v0 >> Ground(pin 09) inAir4 CK >> GPIO 11 (pin 23) inAir4 SO >> GPIO 09 (pin 21) inAir4 SI >> GPIO 10 (pin 19)

thomasverbeke commented 8 years ago

this is an assertion error; so your device is not in SLEEP/STDBY or FSK_STDBY mode. you can manually poll the register (look at my fork for examples) to check what mode your device is in; if you have a working spi implementation this should be very easy to test.

I would occasionally get this error when my lora device was already in continuous reception or tx mode; then the assertion would fail and the only way to quickly solve this problem is to reset my board (since I included an easy reset button on my pcb).

You could also get this error of course If you have bad connections for the SPI communication lines (MOSI/MISO/CLK/Slave select) due to bad soldering and I think this is what dmahony is refering to.

Good luck!

jsonpoindexter commented 8 years ago

Thanks @thomasverbeke for the response. Right now I am going to trace down my soldering job. Looking over it again it doesn't look so good. I will let you know how that goes.

Thanks again!

mayeranalytics commented 8 years ago

@KentuckyFriedFrank The pinout looks ok to me. You have the inAir4 with SX11276 or SX1278. The Medtronix specs say: "This module can be assembled with the SX1276 or SX1278 chip. Both chips are identical when used for 433MHz operation." But the frequency ranges do indeed differ: SX1276: 137 - 1020 MHz SX1278: 137 - 525 MHz So maybe you're on the right track with your suspicion that you shouldn't change to 868MHz.

I don't yet see how this would explain the assertion failure, though - the assert is called before the frequency change is attempted. But I'll have a closer look.

In any case it's not a good idea to switch to 868MHz when you have the 433MHz circuitry and antenna. I added an additional parameter to LoRa.init that lets you pick another frequency for calibration than 868MHz. (The default is still 868MHz, though!) Maybe the calibration in LoRa.init should be optional, anyway.

dmahony commented 8 years ago

My tranceiver was connected correctly, Its just the soldering needed redoing then it was fine.

jsonpoindexter commented 8 years ago

@mayeranalytics thanks for the follow up! I see in LoRa.py Line 92 the changes you made: 968 >> calibration_freq (which calibration_freq is set to 868 on line 84). I am just curious why the change from 968 to 868.

jsonpoindexter commented 8 years ago

After re-soldering all solder joints I am still getting the same issue. Even with the new code and setting calibration_freq = 433.

I will let you know if I make any progress.

jsonpoindexter commented 8 years ago

I really do not know what is wrong. I have verified that SPI is working using communication via SPI with an Arduino http://mitchtech.net/raspberry-pi-arduino-spi/ as well as the LOOPBACK TEST https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md. I have also verified the pins are good and making a connection to the RPI pins. I have also swapped out the InAir4 module with 2 others and have the same problem.

Does CS need to be attached to a GPIO?

jsonpoindexter commented 8 years ago

Does CS need to be attached to a GPIO?

This was what was causing the issues. If only there was a Head-to-Wall emoticon on GitHub...

My final pinout: inAir4 DIO0 >> GPIO 22(pin 15) inAir4 DIO1 >> GPIO 23(pin 16) inAir4 DIO2 >> GPIO 24(pin 18) inAir4 DIO3 >> GPIO 25(pin 22) inAir4 Reset>> NA LED >> GPIO 18(pin 12) inAir4 VS >> GPIO 04(pin 07) inAir4 3V3 >> 3.3v(pin 01) inAir4 V0 >> Ground(pin 09) inAir4 CK >> GPIO 11 (pin 23) inAir4 SO >> GPIO 09 (pin 21) inAir4 SI >> GPIO 10 (pin 19) inAir4 CS >> GPIO 08 (pin 24)

Thanks for your help everyone!

mayeranalytics commented 8 years ago

@ KentuckyFriedFrank 968 is a typo. 968MHz is not in any ISM band.

On 29 Mar 2016, at 01:53, Jason Poindexter notifications@github.com wrote:

@mayeranalytics https://github.com/mayeranalytics thanks for the follow up! I see in LoRa.py Line 92 the changes you made: 968 >> calibration_freq (which calibration_freq is set to 868 on line 84). I am just curious why the change from 968 to 868.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/mayeranalytics/pySX127x/issues/7#issuecomment-202631747