higher data throughput with few duty cycle/time on air limits
OK… I would LOVE to use a couple of these in my current project… but have a query re antenna. Ideally, I’ll put a second Pico plus Transceiver inside my power meter box… a nice Faraday cage 
Quesion: is it possible to connect an antenna that I could mount on the outside of the meter box? Transmitter and receiver will be less than 4m apart… yes, 4m. But will save me digging up 4 m of pavers and burying cable …!
Failing that (and assuming it just won’t work if the receiver is inside a metal box), I could possible mount the whole thing (Pico + TX/RX) externally, but internal controller with external antenna would be better…
Are there any other solutions that might work with a Pico?
Thanks,
T.
Hi Trevor,
Unfortunately, the antenna is built into the PCB so you can’t wire an external antenna to the PiicoDev module. Fortunately, we use a common 915MHz radio so there are plenty of other boards that can be used with ours.
This microcontroller for example has the transceiver embedded with a spot for a uFL connector for an external antenna.
Thanks Jack… I don’t see a u.FL connector on the microcontroller you linked to… but this one does.
I had decided to just stay with Pico, and put the entire thing outside my meter box, but now I’m swinging toward biting the bullet and running with the Feather board and external antenna.
So my transmitter will be Pico… receiver - something else. I’m trusting that if they are both talking over the same 915 MHz channel, it will all work out. I have zero experience with radio stuff… any advice from others very welcome!
Cheers,
T.
1 Like
It doesn’t have a u.FL connector but it does have the pads for an external antenna to be soldered to it.
The antenna on the FeatherS3 appears to be for the 2.4GHz radio of the ESP32. As far as I can tell it doesn’t natively support 915MHz signals.
Returning to the forum after several weeks working on software… I did some tests on my PicoDev Transceivers, attempting to discover some device characteristics. Like… when is the receive buffer cleared? Why do I ask?
I was doing some latency tests last night… this AM, I wanted to test what happens if multiple messages are sent before the receiver issues a .receive call. To my surprise, the test messages I sent this AM went into the ether… but the receiver did report it received a message I sent last night !!!. Dang…
Did another test… set up my receiver to sleep for 5 seconds between loops… while my transmitter sends 4 test messages (from the example in the guide) with a 500 ms delay between each. The receiver sees… would you believe the FIRST and LAST messages… and loses number 2 and 3. What ??? It is repeatable…
And, oh, BTW… the two units are sitting about 20cm apart on my desk. No distance issue. And in my “real” code, I’ve been working happily with sleep_ms of 400 ms… or less after each .send. 500 ms should be sufficient, AFAIK.
PS Just repeated my test with a full second delay between send on the transmitter side. Exactly same result on receive side.
Edit: Oops… found I had a bug in my receiver code, things are not quite as bad as I describe above… but still, some messages definitely go missing.
Maybe the answer to my own question is this: Always, with high frequency, check for received data. This might solve the problem…
Any help appreciated,
T.
Hey @Trevor277988,
I do think the safest option is checking for received messages, though I am curious why the loss ratio seems particularly high. 50% of messages being lost to the void is not ideal. Additionally, if you need full back-and-forth communication, then this issue can go on forever, classic two generals problem comes to mind.
Where are you performing your tests? Heavy interference could be caused by wireless communication devices near your bench/desk, though I expect this was forefront of your mind while testing.
Regardless, the RFM69HCW datasheet contains extensive information about the performance of the onboard chip, as well as the equations used to determine key functionality. If you’re no stranger to scouring datasheets this could yield some great info. I’ll link it below.
Additionally, we have full schematics for the PiicoDev board on our hardware repo, if you’re interested.
Hope this helps!
Having worked in computer communications for many years I always find myself coming back to writing code similar to what we developed years ago on very old computer systems. Messages sent as packets with packet numbers in each message. If a packet missing ask for retransmission. I find it amusing this still works today.
Lucky for me most PiicoDev TX/RX I have done is very very very basic stuff. I have noticed the receiver on the PiicoDev TX/RX keeps whatever message it has received until it is read from the buffer or powered off.
This is amusing when the program crashes and the PiicoDev TX/RX receives a message from something. When the program is started again the message is the first to be read from the buffer. Made me write code to read the buffer till empty on power up.
Cheers
Jim
1 Like
Thanks Zach… I will examine the datasheet… tomorrow. It’s 1:48 AM, and I only just saw your post!
I did screw up a bit in my initial test - the results are not quite as bad as it first appeared, but there is definitely some weird stuff going on… which seems confirmed by Jim’s comment.
In my app, I do a read before proceeding. I also tried calling rfm69_reset… but, unless I’m mistaken, on at least one test this still did NOT clear the read buffer. More testing later… for now, my setup is fairly functional.
When I have some idle time, I might actually try hacking the driver, but don’t hold your breath… I still have a lot of work to do on my current project!
Cheers,
T.
1 Like
Hi Trevor,
I have also tried transmissions over similar lengthy distances of at least 30cm! (although I did run a test from 15m away and through a couple of walls)
One unit transmits atmospheric data every few minutes, but I have the receiver running at a much higher refresh cycle of 5 or 10 seconds. Perhaps by luck, or because I’m reading so much more often than transmitting, I haven’t missed any data ‘packets’ or had any problem clearing the buffer.
Is a faster read cycle something that you can try?
Cheers, D
1 Like
I can easily do my reads more frequently… and this might just be the safe solution.
I’d still like a better understanding on what’s going on under the hood… but I have bigger fish to fry 
Cheers,
T.
1 Like
