Interesting overview but what I want to know is EXACTLY what sensors you have on your devices.
So I can see what the likely space used on the device.
Interesting overview but what I want to know is EXACTLY what sensors you have on your devices.
So I can see what the likely space used on the device.
In the meanwhile, you could try adding the device again, but ensuring you check the Resets Frame Counters - it doesn’t work so well if you do it after you’ve created the device.
And these are ALL of the EU frequencies (which also apply to UK, Swiss & EEA Bees).
Sorry, I didn’t catch the accuracy of your question : on the concerned device, I have 2 scales , 1 voltage, 1 T° , that is to say 30 or 33 bytes for payload .
Is it the responses you expect ?
Here is one received message copied from the gateway console V3:
19:36:17 Receive uplink message DevAddr 260BA800 FPort 1
MAC payload A519304F80688C42BB2F21539A0A063BC30D0BA1
Bandwidth 125000
SNR 7.5
RSSI -31
Raw payload 4000A80B2680000001A519304F80688C42BB2F21539A0A063BC30D0BA10A5BCD2F
Reset frame is already checked ; I add immediately the 5 missing frequencies and come back.
OK, perhaps some Pilot Induced Oscillation - far too much information, just need the sensors on the device. This Bee is an OCD Geek.
What is the brand and model number of the temperature sensor?
But quite probably not working - which is why I said:
But worth adding the other frequencies as a first test.
I check Reset Frame right at the device creation since V2 version ; definitively
I check Reset Frame right at the device creation since V2 version
Not sure if this is clear to me, what is v2 in this equation?
When you created the device on v3, did you click Resets Frame Counters BEFORE you saved changes.
When you created the device on v3, did you click Resets Frame Counters BEFORE you saved changes.
YES : it is clearly mentioned in the beelogger tuto and i read a lot on that counter to be reseted.
But worth adding the other frequencies as a first test.
No changes …
you can see on the following image the 2 other devices that I can still read on Stack V2, the first line shows the device created on V3 :
What is the brand and model number of the temperature sensor?
DHT 21/22 is configured but I don’t implement it .
I use the T° information from the DS3231 module (RT clock)
For Volt, Nano board analog input are used.
You can use also a DS18b20 sensor for T°
DHT 21/22 is configured but I don’t implement it .
Does this mean it is wired to the Nano?
Does this mean it is NOT used in the code?
You can use also a DS18b20 sensor for T°
I am asking what you are using on your device so I can check the compiled size.
I think we have now established that you have the HX711 and a DS3231.
Is there anything else (apart from the SX1276 & the batteries) that is wired to the Nano?
Please do not embellish.
Can you see the serial output from the device so we can tell what is happening?
Can you see the serial output from the device so we can tell what is happening?
I have to go on the hives but the weather is really poor (let’s say a bit Brit…). We will have to wait until bees can go out also …
I will have the time to read more .
Thanks anyway
I’ve used up to 3.3.0 and am in the process of testing 4.0.0. It requires a Serious Geek Bee to set the library up to allow it to fit in to a Pro Mini / Nano and even then with the sensors you use it may not fit on the device, but let’s not worry about that now.
This was the right direction : with an updated library ,tonight i have some better results. Some messages are properly decoded at the level of the console. They do not reach my server presently but it’s a great step already. Tomorrow is an other day !
Thanks for your help. It has been a pleasure to fly with you a moment.
See you later.
Dear Descartes, please find the information on the message transferred :
at the level of the device :
07:28:12.806 → Payload
07:28:12.806 → 5 T°-Out:2125
07:28:12.806 → 1 V-Batt:7727
07:28:12.853 → 2 V-Sol:3
07:28:12.853 → 3 65 FC1F Gewicht: -993
07:28:12.901 → 4 65 939 Gewicht: 2361
07:28:12.901 → Length ; 20
07:28:12.901 → Packet queued len:20
07:28:14.173 → 11413143: TX Complete!
07:28:14.173 → Cnt:113 bs:0 wr:1
07:28:14.173 → Wakeup:7:33
at the level of the Device console :
Forward uplink data message
Payload decoded
analog_out_1 77.27 ; analog_out_2 0.03 ; luminosity_3 64543 ; luminosity_4 2361 ; temperature_5 212.5
Raw Payload
0567084D01031E2F020300030365FC1F04650939
FPort 1
SNR 10.5
RSSI -32
Bandwidth 125000
Analog out fort Volts, luminosity for Weight, T° for Temperature. This work fine now with the proper LMIC library .
Now I have to understand why I cannot read the MQTT server V3 such as in V2 . But this is an other topic , if I have well understood.
Bye on that one.
Thanks . Very interesting information in it
Have a good day
hi, i also run multiple bee sensors. the setup is :
when moving from v2 to v3:
ttn_config = {
‘devaddr’: bytearray([0x…]),
‘nwkey’: bytearray([0x…]),
‘app’: bytearray([0x…]),
‘country’: ‘EU’,
}
then i had to totally rewrite mqtt handler as V3 has different format then V2 (this makes sense)
there was only one pitfall: if you start fresh device and your frame_counter start at 0, then mqtt payload is missing key: [‘uplink_message’][‘f_cnt’]
(but probably i should start with 1 not 0)
pavel
if you start fresh device and your frame_counter start at 0, then mqtt payload is missing key: [‘uplink_message’][‘f_cnt’]
That is a ‘feature’ (according to some, others consider it the error it is) of the V3 backend. You can start your counter at one if you want to or just catch the ‘missing’ field by defaulting it to zero.