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 116 forks source link

Weird behaviour using the beacon class for some bytes #6

Closed thomasverbeke closed 7 years ago

thomasverbeke commented 8 years ago

When sending some byte for example "0x00", or "0x67" the interrupt (TxDone) will not be generated the third time. This is a very weird bug? It can be reproduced by changing the 1-byte message (0x0f) to 0x00 or 0x67 for example in the beacon. When extending the message to multiple bytes the same thing will happen when these bytes are part of the larger message.

mayeranalytics commented 8 years ago

Very weird. What board/chip are you using?

thomasverbeke commented 8 years ago

This happened to me a long time ago and if I remember well it was related to a bug in your code which I fixed in my fork. I will review my code tomorrow to see how I solved it.

I'm using a developer board from semtech (sx1276)

Abrasam commented 8 years ago

I'm having this issue with the HopeRF FRM95W.

bjcarne commented 7 years ago

I would also be interested to know how to resolve this. It seems that any payload I send that ends with binary ????0??? as the last byte (e.g. hex 0xF[0-7]) causes the tx_done to not be generated on the next transmission.

It doesn't seem to matter what any of the other bytes contain, just the last one in the payload is affected.

I'm using Raspberry Pi 2 and inair9b.

bjcarne commented 7 years ago

I have found the fix in https://github.com/thomasverbeke/pySX127x/issues/1#issuecomment-178582087. It is in relation to the clearing of IRQ flags.

Pull request - https://github.com/mayeranalytics/pySX127x/pull/16

I have tested with Raspberry Pi 2 and inAir9B using Python 3.4.2.