Anything more specific than just “hardware reasons”?
Looking at the current state of their software and the lack of any documentation, I’d stick with the TTN software. Also, they responded to one of the issues I raised saying:
[…] Badgerboard is meant mostly for making proof-of-concepts […]
It’s still a nice board, but I feel they should just document the wiring. Or open source the schematics like they promised when it was still a Kickstarter project, so we can figure out ourselves how to use the board. Just my 2 cents though.
I asked them to comment here - I am pretty new to LORA and need to understand how to Your post is highly appreciated - will try to follow when I have time
Just noticed that for “low” temperatures (say 10 ºC, not really low) the FaBo library or the HTS221 sensors report values such as 1212.51 ºC.
These are then sent as negative values, due to the integer 121251 exceeding the maximum value for 2 byte signed integers, which have a range of −32,768 to 32,767. (The hexadecimal value 0x01D9A3 is sent as 2 bytes in 0xD9A3 which decodes back to -98.21 ºC.)
That’s good news, @anni. For the wiring I meant to refer to internal wiring, such as wiring from MCU to RN2438, the sensor, the LiPo charger and all. That would allow people to figure out if something special is needed for the software. However, if the schematics are provided then that is surely covered, nice.
Hi!
I have trying to connect my badgerboard with the bagerboard library with ABP and have no success.
Im using the standard library for bagerboard and Lora_temp_hum_ABP.ino. It’s compiling but I get some error when trying to send “Bootmsg”. I have used the debug and this is what I get.
Configured onboard temp/humidity sensor.
badger temp/hum sensor
devEUI 01:02:03:04:05:06:07:08
Start initABP
[initABP]
[init]
[wakeUp]
[wakeUp]
[resetDevice]
[expectString] expecting RN.(RN2483 1.0.1 Dec 15 2015 09:38:09) found a match!
[wakeUp]
The device type is RN2483
[setMacParam] devaddr = [array][expectString] expecting ok.(ok) found a match!
[setMacParam] appskey = [array][expectString] expecting ok.(ok) found a match!
[setMacParam] nwkskey = [array][expectString] expecting ok.(ok) found a match!
[setMacParam] adr = off
[expectString] expecting ok.(ok) found a match!
[joinNetwork]
[expectString] expecting ok.(ok) found a match!
[expectString] expecting accepted.(accepted) found a match!
[sleep]
[wakeUp]
[wakeUp]
[sendReqAck]
[setMacParam] retx = 2
[expectString] expecting ok.[sendReqAck] Non-fatal error: setting number of retries failed.
[wakeUp]
extrawakeupeakeup
[setMacParam] retx = 2
[expectString] expecting ok.[macTransmit]
[expectString] expecting ok.[lookupMacTransmitError]: accepted
[lookupMacTransmitError]: found 14
LoRa warning: accepted
[sleep]
It’s looks like the string “accepted” is still in the line after the Joinnetwork gets accepted.
Anyone has experience the same or have an idea how to fix ?
I just saw that you have uploaded the schematics. How do I open it? I’ve tried open the .sch with KiCad without success. Isn’t it easier to just upload a PDF or something also ?
Or can you recommend any freeware to open the schematics with ?
Just want to hear how you Badger board is performing; we have had a TTN workshop here in Cph and now I can work on getting my Badger connected Greetings, Gernot
I still had one running that I also used for this topic, so: not using any of the Badgerboard libraries. Looking into that device now:
It had somehow downgraded to SF12 (might be a TTN ADR issue?). Cycling its power made it go back to SF7.
(My code was sending 8 bytes plus a 13 bytes LoRaWAN header, and used delay(5000) in the loop. On SF12, with a total 1483 ms airtime, it was only possible to transmit every 1190 seconds, almost 20 minutes. For SF7 with 57 ms airtime, transmitting was only possible every 49 seconds. These delays were caused by disabling 7 of the 8 default channels. This rightfully caused no_free_ch due to the very low maximum duty cycle of 0.125% for single channel nodes.)
Like mentioned above, when running on a mains adapter, the reported voltage level is always the exact same value (3.283 for this very board, and 3.325 for another one I tested earlier).
The temperature reading this one board gives is about 7 degrees Celcius too high at room temperature. (If not due to it being an onboard sensor, then maybe due to using different libraries; I did not compare to another Badgerboard.)
It does not work on battery packs that have some smart power management, as it draws too little current, making my battery packs switch off automatically
Also, shame on me for not switching it off after I was done testing…
I have the same problem you have with the temperature sensor. It’s reading a couple degrees higher then any other temperature sensor I have.
Also have the same problem with my powerbank. To low current so it switch off after 30 sec or so.
I have mailed badgerboard twice about the faulty temperature sensor and haven’t even got a replay on those mail.
I have also noticed that on their site its says “Stand by 200 uA”. While mine is in full sleep it draws around 400-500uA.
Updated my badger board RN2483 firmware to version 1.03 using the Lora java tools in the ink below, upload the TTN passthough example code first of course - works well.
Maybe I’ve missed something re the voltage measurement side of this thread, but as the atmega32u4 is sat behind the voltage regulator all we can expect is a steady 3.3v (approx, small variations withing the circuit can be expected) regardless of usb/lipo connection and regardless of the lipo charge level, looking at the circuit I am (entirely) guessing that the only way to get the lipo V state is a voltage divider setup?
I have a single channel LoRa gateway with a Raspberry Pi and a Dragino HAT, as a Node I am using a Bagerboard. With the TTN library instead of the original Badgerboard library following this thread by @arjanvanb I got it setup with TTN and working.
Since the Dragino HAT is only a single channel gateway I would like to setup Badgerboard using a fixed channel (868.1 MHz) and a fixed spreading factor (SF 7).
it’s quite impossible to read the ambient temperature with a temperature sensor mounted on the same board so near to other components. In essence it is impossible to obtain an adequate level of insulation of the sensor from the heat sources mounted on the board. Mind you, the heat is spread mainly through the electrical connections and not from the air heated by the ICs on the pcb.
The value read will always be higher than the real one.
Some interesting reading:
PS this should have been known by those who designed this board, or at least, they should have noticed during the tests.
They should therefore advise their customers that the temperature read by the sensor is not the ambient temperature. Or we’ll make this answer suffice for everything
PPS I saw now that the sensor was mounted near the MCU… comfort yourselves because if they had even mounted it in the corner of the PCB would not have solved the problem
Your post is highly appreciated - will try to follow when I have time
