vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 4, 2019 4:12:27 GMT -8
Waverley Amateur Radio Society celebrates 100 years of continuous licensing in January 27 2019. As active "Ham Radio" enthusiasts we experiment and build many things.
The plan is to build a weather station for the club, with a couple of additional features.
- Broadcast Weather information over APRS. - Integrate lightning forecast into relay switches and remote equipment to shutdown radios during storm. - General experimentation with LoRa and ThunderBoard in high RF environment. - Create tutorials for club members about:
Arduino Sensors LoRa APRS Data formats.
After a few challenges getting the LoRa modules going things have moved on a bit.
The parts list so far:
OurWeather Weather Kit Solar WXLink LoRa Thunderboard
Suggestions welcome as the build proceeds.
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 4, 2019 4:14:04 GMT -8
I have designed a built a prototype case for the Remote Module and the Base module. The remote module is out on thingiverse. Search for 3403158 or SDL Remote WX Solar Weather Case Thing 3403158 (I'll have to work out where this viglink stuff comes from in the links.) Here is the Remote Case. The Base module needs a bit more work before I add that.... However it is just a simple 3D box. .../alex VK2PSF
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 4, 2019 4:35:36 GMT -8
At the moment I am experimenting with passing the Solar information back over the WXlink and onto Blynk.
I have modified SDL_Arduino_WXLink_LoRa_TX and RX to pass and receive the Load Voltage over the Aux1 field.
Was there a particular reason to leave it out? My initial code just shoved a 5.0V in the field to make the Watt calculations work. it is handy as I have seen the value move from 4.9V to 5.1V so would be interesting to trend over time.
I have then modified SDL_ESP8266_WeatherPlus to look for a switch setting to send the WXLink Solar/Battery/Load Volt and Current to Blynk in the SAP fields if their is no local Solar Module, actually my current method will overwrite the local anyway. However this will do for now.
Basically the issue I have is that I can increase local "RF Noise" a bit, and then the link stops receiving the data. So this brings a couple of things up 1. probably need to move to 915MHz anyway as we have a lot of 430-450MHz experiments and activities, and 43x is very noisy in Sydney. 2. Rewrite the error handling a bit. a) Pass up the chain if the last WXData is getting stale. If the last WXData packet was good then it keeps sending the same data to Blynk. b) handle not receiving a packet good or bad after timeout. c) there is basic handling for a corrupt packet already.
All right, enough fiddling now to get proper fork setup and start looking at the code. .../alex
|
|
|
Post by T3chDad® on Feb 4, 2019 10:05:59 GMT -8
Nice! Looks like some good 3d design and printing.
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 5, 2019 19:55:49 GMT -8
OK, after some testing... still have not resolved where or why link problems but some observations. If the receive gets a good packet then it will keep posting that packet to Blynk and the oled. It can fail on the receive side for minutes or hours and then receive a good packet. Or it can get several good in a row. The Tx stopped stopped after 90 minutes - not sure if it was because I was running from console cable. Also the Tx is set to full power... if anything this might be too much in this test scenario... will look at reducing power. So the test setup now: Transmitter - SDR Receiver - SDL Receiver in the background Additional receiver without i2c connection Waterfall with 1 min tx over 5 minutes
|
|
|
Post by SDL on Feb 6, 2019 18:00:34 GMT -8
How about doing a quick guest blog for us on our 3D printing for this project. I'm sure lots of people would be interested!
BP
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 6, 2019 18:10:50 GMT -8
Yep, happy to give that a go ... but for now trying to get the thing working..... refer my post in the WXLink support forum!
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 6, 2019 19:00:53 GMT -8
Confirmation that I should use the seeed library, excellent thats one piece of the puzzle nailed down. Standard TX build (without my load voltage mod passed via Aux). No DS3231. Tx unit stops sending data over rf after 19 messages. Roughly Message 0, 11, 18 and 19 seemed to be received. However by staring at the screens waiting for a dropout..... The WeatherPlus board rebooted shortly after msg 0 and 11. these messages...Although it appears the RX mini didn't as the message was available in it's buffer and was read on the next i2c loop. So that actually disproves my other observation.... the unit doesn't start sending again. The WeatherPlus reboots and rereads the last message so the time since last good message seems shorter than it really is. This is good we are working the problem down! The one thing I will try is to reduce the Tx power more.... my test scenario is really close together and I think there could be some desense going on. Quick edit Dropped power to lowest 5 and the test receiver is now at 100% decodes (this unit runs part of the standard Rx code without the i2c interface) so desense was part of the problem.
|
|
|
Post by SDL on Feb 7, 2019 13:30:18 GMT -8
VK2psf,
Boy, I like your hardware. What are you using for your tests?
Now, regarding the desense. That could explain the differences I've seen on deployed systems. And why sometimes I've had hard times testing things in the lab.
BTW, frost heaves outside on my PVC pole outside test unit listed the pole all the way out of the PVC sleeve in the concrete and it came crashing down, destroying the anemometer and wind vane. Soon as it gets warm for a few days (currently at 7 degrees F) I'll go out and patch it up and get it back up. Looks depressing laying in the snow.
Then I can start doing some more testing with GWP and OurWeather.
John Shovic
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 7, 2019 14:50:17 GMT -8
The RF monitoring is just done with $25 RTL-SDR units and gqrx. I built up a unit with 2 dongles using a LattePanda Alpha. ok back to first principles on the debug.... looking at the output from the Tx log it's looking like the AM2315 is causing the lock up. However time to gather some test results... Modified the Rx debug to just output the timer field (deciseconds), messageid, RSSI, and then L for Loop and D for the start of a received packet. Transmit - powered via FTDI header, No DS3231, AM2315 connected but readloop commented out, SAP disconnected. 338156;1021;-23;LLLLLLD 338487;1022;-23;LLLLLLD 338818;1023;-23;LLLLLLD 339149;1024;-23;LLLLLLLLLLLD 339811;1026;-23;LLLLLLD 340141;1027;-23;LLLLLLD 340472;1028;-23;LLLLLLD
approx 78% received over 9 and 1/2 hours
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 7, 2019 19:50:11 GMT -8
Quick test 2 - Tx Board running on SAP battery. No DS3231, AM2315 still commented out. 84% packets ok. So next test is uncomment the AM2315 parts.
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 8, 2019 4:27:00 GMT -8
So several tests... basically the AM2315 seems to be the issue. First test was SAP - Battery - AM2315 - got around 70 messages before locking up. Restarted (Switch SAP off/on) got about 25 messages. Restarted got about 10 (maybe the Battery Voltage getting down to 3.99 is part of this?)
Next connect SAP to USB to start charging battery. about 10 - 12 messages before lock ups. Last was remove SAP control interface but still power Tx board. 14 messages.
So time to get some of the grovepowersave devices and read up on using the SAP and/or another watchdog. In the meantime I will start experimenting with antennas and leaving the box outside (with the 2315 disconnected).
|
|
|
Post by SDL on Feb 8, 2019 6:18:09 GMT -8
We are working an AM2315 reliability issue (but one that happens much, much rarer than your problem).
The fix we are trying now is under:
~/SDL_Pi_GroveWeatherPi/SDL_Pi_AM2315.AM2315.py
Change
MAXREADATTEMPT = 10
BP
|
|
vk2psf
New Member
Posts: 24
Raspberry Pi: Yes
|
Post by vk2psf on Feb 12, 2019 16:30:24 GMT -8
Less is More After going down some interesting paths I have settled on swapping out the SunAirPlus with a SunControl board (Yeah Kickstarter!). I can use the SAP with external watchdog in a bigger project. I looked into the AM2315 counters, I saw that there is some code already in the library to try this. I may come back to this later when my GrovePowerSave units arrive. I then got a bit too tricky with this... Initially I connected the watchdog ResetN to the Arduino Reset. However if the i2c was hung then that bus would still not restart. So I added the USB Power Control and a test on the Arduino to see if the bus was hung. Using some code from here I2C_Clearbus to decide if I needed to powerdown. The Arduino would then initiate a powerdown... this didn't work reliably, it usually left the Arduino hung. So finally a simple cable from USB Control to the Watchdog pins on the SunControl board, and just powerdown/up if the watchdog doesn't get patted. The DS3231 is somewhat optional, but as I have the reboot function shouldn't hurt to leave it there. I also made a simple power cable from the 5V pin header of the suncontrol to the Arduino. Just waiting on a larger battery (4400) to finish up the unit. Running out on the Balcony now, so we will see how things go after a few days.
|
|
|
Post by SDL on Feb 13, 2019 14:02:36 GMT -8
Excellent set of tests and debugging. Funny that I don't see the AM2315 hangup on our unit here (currently barred under a couple of feet of snow due to frost heaves knocking the pole down).
One thing to try, is remove the DS3231 and let the software free-run the software timing loop. I found that the DS3231 would hang up occasionally and the software timing (not quite as accurate) is more reliable.
BP
|
|