Following the recent posts in the Workbench thread:
Covering the 5205, some strange battery & GPS performance and issues that followed I thought I would update here on how the POC packaging has gone and some basic results:
I tried both the SMA & iPX versions and used in simple scale-able 3D printed housings like these:
Assembly was simple…LoRa patch antenna and the GPS Lozenge were mounted in the lid
The 5205 board was then the meat in the sandwich:
With the Battery as final layer before the the base plate fixed in place with 4xm2.5 screws/bolts.
For powering/charging the units before the planned Qi wireless charging solutions arrive either a short usb cable was attached to the onboard socket or a small access hole was cut/melted into the end to allow external usb supply.
As I had a spare earlier V1 811 Tracker/breakboard and had printed a few spare/alternate sized cases I also packaged up one of these
As I wasn’t too sure of what to expect from the small LoRa patch antenna I’ve taken a few drive arounds with the trackers set for 15/30 min position updates. As I was looking for >0.5km range with patch and >2km with the stick ant I was pleased to see examples like these with just the patch:
and driving around the Bourne End & Cookham community within range of several GW’s (Flackwell Heath, Cookham & Burnham) I managed to grab this:
Exceeding expectations without any specific optimisation or refinements.
Well done @rakwireless@fomi@kenyu and the team
Next steps are to improve overall performance and move to final housings vs these temp 3D simple boxes, develop the software to improve resiliance - at the moment I see a strange behavior where if I let the battery run down too far to point where device drops out and then simply recharge, the unit doesnt restart or rejoin each time and I have to open case and hit reset I may have to provide a simple external mechanical option for pushing if I cant fix restart.
These initial units will be used for POC customer demo (the integrated version - iPX - used for asset and animal tracking/location, and the SMA versions with more effective/flexible GPS and stick ant for plant/vehicle tracking/locating) and as the basis of some planned LoRa/LoRaWAN training for a few local clients
Also now waiting to see if I can get some examples of the RAK housings flagged by @BoRRoZ above to compare.
I bought one RAK5205 in the enclosure in the The Thing Conference at Amsterdam. I am testing for couple of weeks. Some impressions:
I am not sure if the root cause is the GPS internal antenna, but with box stopped at same place the GPS is showing differents positions with, sometimes more than 200m of diferences between location points
At night, after a sunny day, I mean sun enough in the solar panel to charge a LiPo 1100mAh battery, the battery charge don´t support the operations more than 3 hours. In the next day after the sun back to solar panel, the box don´t turn on automatically. What I know about LiPo that they should operate under 3.0V if you want a good battery life.
I am using TTN with Cayenne integration and I can´t find the battery charge level information or something related to battery.
I think that RAK is making their products better day-by-day. My suggestion is a better and clear manuals and a better logic distribution of the content in the Github. I am still looking for the payload documentation
See my post wrt the tracker in Workbench thread referenced earlier - I saw same issue wrt GPS - close to window but still indoors - once I placed in large conservatory with wide view of sky or use outside in open areas the GPS behaves as expected.
Had/have same issue wrt battery life (using 1200mA or 800/900mA batteries and only get decent run times when I use preference config after reset to back off both the app update and gps update times…getting days of run-time.
Payload is Cayenne LPP so integration is easy - eventually as the various functions TX their respective payloads - temp/Humidity/GPS/barometric pressure/Accelerometer/battery level you should see dashboard elements gradually populate…the battery level should come through as an analog value - just change the label in settings to battery/charge level If you are not seeing that come through check if you see it in the TTN console - look at you application data for the device - you should see all the different elements coming though…
Glad that worked
Grab the 5205 WisTrio user manual fro the RAK docs site and look to the configuration commands. If you have a serial (via usb port) terminal open then immediately after board reset and self initialisation <messages will appear setting region, initialising teh MEMS devices etc.> you will see message that it is ready to configure preferences…you have a short time then before it starts full operation & join process etc and fixes operating modes during which you can use at commands to set parameters e.g. at_app_interval: etc. Settings then survive following board resets & cold boots…
I openned a request at RAK support and they ask me to take a picture of GPS Internal antenna. I think that they have a suspect of a problem at antenna. In this prototype board sometimes they find a problem and then they change. Well this is the price of “agile method”
Hello everyone I just connect my 5205 tracker update the firmware (fw RAK811_HF_trackerboard_V220.127.116.11.bin) and perform the otaa process to connect the device to TheThingsNetwork but the association failed (Join Failed!).
In my application I receive the data from dev addr and app eui, only that.
I saw some comments about the fw and the violation of the time of use of the air. Therefore, I would like to know or recommend me which fw to use or how to modify the time of sending messages.
I have little knowledge about the RAK5205 but reading about that it does not reach its advertised sleep mode power consumption the following could play a role:
Are all sensors (e.g. BME680) and peripherals (e.g. GPS) properly configured to use the least power before the MCU enters deep sleep?
If not, they may draw significantly more power (assuming they stay connected to power when the MCU is in sleep mode) then when properly configured for least power use.
Is a circuit diagram of the board available? A circuit diagram would allow to check if the advertised low-power/deep sleep current is possible at all, from hardware perspective.