I have been trying to diagnose some very odd behaviour observed on my Piico Transceiver modules… which led me to delve more deeply into the driver provided (PiicoDev_Transceiver.py)
What I found is the register addresses in the driver look VERY different to the register address in the HopeRF-provided Datasheet for the RFM69HCW radio device… which is what is listed on Core’s product info page for the Transciever as the radio chip used. Nevertheless… the device seems to work with this driver… most of the time!
Can somebody please advise? Am I looking at the wrong datasheet?
Did you see my email about weird data found in my receive buffers? I first wanted to check if there is a method to poll the receiver’s ready status, check I wasn’t doing something wrong there, instead of sleeping for a bit and hoping for the best (I did of course do some stress tests… but I digress)
I see on the repo there are some stress tests… I’ll run those also, but it is still quite the puzzle how data (similar to your stress test… ie, writing “ABCD…XYZ” sort of string, could at some later point, even after several reads… and even after completely restarting my python script… could be presented back in the read result. That is just way out there weird… should NOT be possible!
Anyway… more testing to be done - thanks for your input!
Haven’t played with these for a while, but sending what I thought was a basic ‘csv’ string took a bit of messing around with formatting, in python, for numeric inputs (eg, temperature, etc, every minute).
I also ran the Rx cycles about 3 times faster than the Tx (eg, 20 sec). Once a message was received, I read it and used radio.off / radio.on to clear the buffer. This may have been a bit ‘brute force’ but it got rid of received messages, which seemed to accumulate in the buffer.
Thanks David… I found some of the stress tests on the Core repo in need of tweaking… and am too flat out with more pressing issues at the moment to work on it.
I was not aware radio.off/on cleared buffers, but I guess it makes sense.
Unfortunately, I have modified my code that generated the inexplicable sequence I logged, so repeating it won’t be easy - if possible at all. The current state of my code is that I have fully asynchronous bidirectional comms happening… with rather short sleeps (milliseconds, not seconds), and things seem to be working so far. Good… but that weird debug log sequence does concern me.
At some future time I intend to develop what I have into a general purpose library… I already have ACK/NAKs, timeouts and retransmissions working just fine… so am well on the way to a more streams-like protocol. A long way short of a replacement for TCP/IP and UDP… but a step in the right direction!
But… it all assumes a rock-solid driver underpinning it all. And my confidence has been a little shaken.. if not stirred
Cheers, T.
EDIT: PS David… the weird sequence I referred to is not in this thread… it was email sent directly to support. The essence of it is that after running a test script that sends a string containg “ABC…XYZ012…89” a day or two earlier, I then ran my app code which sends short messages, and gets replies from the Rx… I logged that after several send/read loops, one of the replies I got contained the expected reply OVERLAID on the “ABC..XYZ” thing - which of course should not be possible. But I captured it in my logs. No idea how this can happen - but it is a worry!
Great discussion - what about the stress tests do you think need tweaking?
Sorry to hear your confidence has been altered like Bonds martini - I can assure you that many many engineering hours went into designing the hardware and software for that board.
Hey Liam… I’ll get back re the issues I found in the stress tests and other scripts… after I nail my current issues
Didn’t know about the separate board… the Transceiver board with I2C etc is fine… and I can see that a lot of effort went into it (including writing the interface between the RFM69 and the ATtiny). And I have been using a pair of these pretty successfully for nearly a year now, so am happy to endorse the product… but for my current efforts, a little more documentation might help…
