Duh!
Just realized that the node is sleeping while waiting for the message!
There are no debug messages while waiting, the node just sleeps.
What threw me off, was that the time and date are received OK, but that was at the beginning of the first loop, while the node was awake.
I'll try the request() function ASAP.
Thanks.
How about a version with the SDA & SCL pins also routed to the header?
Sensors like the Si7021 are using the I2C interface
OK, problem solved.
First of all, I stopped using SoftSerial, and I am now using the regular serial port.
I can't debug the node any more, but it is working.
And the drain dropped to 1.9 mA.
This is the US100 idle current, so that was also a problem.
So I chose to power the sensor from pins 3 & 4, as VCC and GND, since just using pin 3 and GND kept the drain to 1.9mA
I turn pin 3 to output high and pin4 to output low, wait 5 seconds to let the sensor stabilize, since it gave erratic readings with anything less, take the measurement, and turn pins 3 & 4 to inputs, so there is no drain.
Seems to work so far, after a whole day of taking readings every minute, I am down by 10mV. I intend to take readings every 2 hours in normal operation, so I figure the batteries will last for about a year.
I am writing this from my phone, so I cannot post the source if anyone is interested, but let me know...
@mfalkvidd sorry, I was talking about the US-100 distance sensor. Jumped the gun here.
@Nca78 So, the capacitor is on the other side of the board, it just doesn't show in the photos. No problem with the SMD components, they are large enough if you are a bit careful.
You are wasting precious time writing in the forums. Get back to work! 
@electrik Going through the documentation of the Orangepi, I found out that the config should be
--my-rfm69-irq-pin=71 --my-rfm69-cs-pin=233
but still no dice. I also get an error:
Mar 28 14:11:14 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=0,VER=2.4.0-alpha
Mar 28 14:11:14 DEBUG TSF:LRT:OK
Mar 28 14:11:14 DEBUG TSM:INIT
Mar 28 14:11:14 DEBUG TSF:WUR:MS=0
Mar 28 14:11:14 DEBUG TSM:INIT:TSP OK
Mar 28 14:11:14 DEBUG TSM:INIT:GW MODE
Mar 28 14:11:14 ERROR Interrupt handler error: Bad file descriptor
Mar 28 14:11:14 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 28 14:11:14 DEBUG MCO:REG:NOT NEEDED
Mar 28 14:11:14 DEBUG Listening for connections on ā]o:5003
Mar 28 14:11:14 DEBUG MCO:BGN:STP
Mar 28 14:11:14 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 28 14:11:14 DEBUG TSM:READY:NWD REQ
Mar 28 14:11:16 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
The IRQ pin is connected alright, the RFM69 module works perfectly on a RaspberryPi or an OrangePi Zero.
It just refuses to receive when used on the OrangePi Zero 2 Something with pin assignements or SPI...
It is a a new SOC, so maybe I should wait for someone with more expertise than me to work it out...
Did anyone manage to make it work on an Orangepi Zero 2?
It compiles (after some tweaks) on armbian, it starts OK, trasport seems OK, it can transmit, but not receive.
Out of the box, it comes with
ls -l /dev/spidev*
/dev/spidev0.0
/dev/spidev1.1
My config:
./configure --spi-spidev-device=/dev/spidev1.1 --my-transport=rfm69 --my-rfm69-irq-pin=2 --my-rfm69-cs-pin=13 --my-rfm69-frequency=915 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003
The output is
Mar 23 18:17:18 INFO Starting gateway...
Mar 23 18:17:18 INFO Protocol version - 2.3.2
Mar 23 18:17:18 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=255,VER=2.3.2
Mar 23 18:17:18 DEBUG TSF:LRT:OK
Mar 23 18:17:18 DEBUG TSM:INIT
Mar 23 18:17:18 DEBUG TSF:WUR:MS=0
Mar 23 18:17:18 DEBUG TSM:INIT:TSP OK
Mar 23 18:17:18 DEBUG TSM:INIT:GW MODE
Mar 23 18:17:18 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 23 18:17:18 DEBUG MCO:REG:NOT NEEDED
Mar 23 18:17:18 DEBUG Listening for connections on PāE:5003
Mar 23 18:17:18 DEBUG MCO:BGN:STP
Mar 23 18:17:18 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 23 18:17:18 DEBUG TSM:READY:NWD REQ
Mar 23 18:17:21 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
I tried also with the development branch (fewer tweaks) but with the same results.
Any help would be appreciated
It's a known bug (or feature) of the Rspberry Gateway + RFM69. RSSI values are wrong, so you cannot use ATC
What I do, is i use
#define MY_RFM69_ATC_MODE_DISABLED
#define MY_RFM69_TX_POWER_DBM 0
and set the TX_POWER_DBM to the lowest value I can, by trial & error...
Have you guys considered using a US-100 ultrasonic sensor instead?
It can be used in the usual "ping" method, or in serial mode, in which case you can also get a reading from the built-in temperature sensor, and the distance measurement is automatically temperature compensated.
And it also works reliably at 3V.
I was using it for a year without problems in an diesel tank, and made the mistake to replace it with a TOF sensor. Now I'm back to the old reliable US-100.
It's even simpler than that. Just add a line as the one below:
#define MY_SIGNING_SIMPLE_PASSWD "mypassword"
@gohan I meant multiple gateways on the same raspberry.
Right now, I have an NRF24L01 gateway, Domoticz, pi-hole, and a VPN server running, with 2 more gateways connected, one local and one remote RFM69 on ESP8266.
It would be nice if I could combine the two local gateways, the RFM and the NRF on the same Raspberry's GPIO...
@gohan Nice. I was thinking to do that same at some time, but I wasn't sure if the Raspberry could handle the load, since I also run domoticz on it, along with pi-hole.
How many devices do you have on each gateway?
@rolo6442u From what the node itself reports from transportGetSignalReport(SR_TX_POWER_PERCENT). It starts from say 50%, and after a coule of transmissions it goes up to 100%, when the nodes are 1m apart. When using a stand alone ESP8266 gateway, it drops to 0%.
I'll have the nodes ready in a couple of hours, after I come home from work...
@rolo6442u I built an Raspberry gateway using an RFM69 radio, to replace one built around a NodeMCU.
All nodes are transmit only, and using the latest stable API.
I noticed that all sensors were using max TX power after the first couple of transmissions, although they were respecting the ATC setting before, and were using minimum power most of the time.
Now I am concerned about battery life, so I switched back to the NodeMCU gateway, waiting for a fix.
I'll put together a temporary net, with a RPi0 gateway and a single node later, to show some real data, if you need any more information.
Has the issue with RFM automatic transmission control been addressed?