WeatherBalloonV2

1. In RF24.h, change the pins for CE and CSN as necessary, and make sure the radio.printDetails() call is not commented.
2. In WeatherBalloonV2.ino, uncomment the #define DO_SERIAL. This should cause some output to be printed to the serial monitor.
3. (maybe) Comment out the BMP280_setup() and GPS_setup() calls. In my case the program flow was getting stuck in these due to those devices not being present, and the serial monitor showed only "wire error". For now we just want to call RF24_setup().
4. Run and check the serial monitor (9600 baud), it should show something like this:

   STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
   RX_ADDR_P0-1 = 0xe8e8f0f0e1 0xe8e8f0f0e1
   RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
   TX_ADDR = 0xe8e8f0f0e1
   RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00
   EN_AA = 0x00
   EN_RXADDR = 0x03
   RF_CH = 0x4c
   RF_SETUP = 0x27
   CONFIG = 0x0e
   DYNPD/FEATURE = 0x00 0x00
   Data Rate = 250KBPS
   Model = nRF24L01+
   CRC Length = 16 bits
   PA Power = PA_HIGH

If there is a physical wiring problem or the wrong pins are used for CE/CSN, these values will be a bunch of zeroes and the data rate will be the default of 1MBPS. So check that data rate is 250KBPS and power is PA_HIGH, RX_ADDR is not just zeroes.

Incidentally, if you commented out the BMP280_setup() call earlier, the program will likely boot loop when it tries to use the baro that was never initialized. If you don't actually need a baro you can comment out the BMP280_loop entry from the tasks[] array.

5. Check that sensor values are being measured correctly.
6. I seem to recall that the serial monitor output interfered with something (or maybe just slowed things down?), so you might want to comment out the DO_SERIAL again for final usage.





RFRXV2

1. Set the appropriate pins for the 'radio' class constructor, and uncomment the call to radio.printDetails()
2. Run and check the serial monitor (115200 baud), at startup it should show a similar display as above for the radio configuration. Some bytes will be a little different because this time it's a receiver, but again they should not be all zeroes.
3. If the transmitter is running, check the sensor values in the JSON. The 'dt' value is the time passed (milliseconds) since the last packet was received, so this should be near zero when the transmitter is running.





Android app

Looks like in the v2 app the log output does not show in the log tab. But if you can see the 'age' value increasing when the transmitting side is not active, then the data stream from the arduino is being parsed correctly.