Hi everyone,
I’ve just finished fabricating and testing a device for portable testing of LoRaWAN networks. Quick overview of its features are:
GPS with onboard antenna (automatically detects and supports an external antenna)
RN2483 (so technically supports 868MHz and 434MHz)
ATSAMD with the Arduino bootloader
Boost converter allows the device to run off AA batteries (so you’re not caught short)
Main settings (ABP/OTAA/Transmit Interval/Spread factor) can be configured using the joystick, only the network keys need provisioning via the USB connection.
Screen lets you see results on the go (number of gateways, spreadfactor sweeps, etc.)
Supports TTNMapper
All the software and PCB files are open sourced, let me know if there’s features that people think should be included within the software.
I use the Link Check mac request for the uplinks, the NS then provides in a downlink frame with the number of gateways that saw the request.
does acknowledged frames in sweep mode rapidly conflict with fair use policies ?
In terms of duty cycle, the RN2483 will enforce the legal limits. In terms of TTN, yes, sweeps will use 6 requests with DLs (currently we don’t force frequencies as all the combinations very quickly add up!). I designed the device as we (at work) regularly had proposed nodes sites where we wanted to understand the quality of the connection and expected behaviour - as such, although sweeps are ‘intensive’ they are likely only to be used occasionally in short bursts. Survey was designed more for ‘war-driving’ scenarios and defaults to manual triggering, with the option to configure a time-interval.
Afraid its not for sale, but the files are there if you would like to make your own. If there’s a large amount of interest I might replace the MCU with a QFN package and see if I can get a small run made.
The tester was a bunch of breadboard parts for a longtime using an off-the-shelf feather; so it’s easier to get going with the software. The pcb is mostly SMD and you will need a device (black magic probe / segger jlink) to program the MCU with the Arduino boot-loader.
We use the LinkCheckReq mac command, which reports the link margin in dB of the last successfully received LinkCheckReq. The interval is set to 0, so every packet the device uplinks has the request attached.
seems to work for me (I can see private NS servers responding back the linkcheck), but thanks for alerting me to it as I’ll need to check its working fine for TTN.
Just curious if you it will work for the RN2903 for 915MHz? I live down under in Australia, so the RN2483 isn’t much help to me.
Just a couple of questions.
You said it was originally a breadboard design with a Feather. I have a Feather WICED M0 and a Feather WICED with an with an ESP-12S, therefore, will it work?
Second, do you have a parts list so I can make it? If so do you have one for both the PCB and the breadboard design?
Just curious if you it will work for the RN2903 for 915MHz? I live down under in Australia, so the RN2483 isn’t much help to me.
In theory should work. We make use of a slightly modified library from TTN which reportedly lets you change frequency plans for the different microchip modules. The interface should also work as the spreadfactors, etc. should remain the same (obviously I havn’t tested this though!).
You said it was originally a breadboard design with a Feather. I have a Feather WICED M0 and a Feather WICED with an with an ESP-12S, therefore, will it work?
Probably not, as I use the sercom interface to create the required additional hardware serials, etc. Similarly the flash storage is tied strongly with the ATSAMD21 (it doesn’t have eeprom, so we have to store in flash).
Second, do you have a parts list so I can make it? If so do you have one for both the PCB and the breadboard design?
I’ll get working on a BOM for both the pcb’s and the breadboard.
Off the top of my head the “breadboard” needs: RN2483 (or possibly RN2903) in a format that you can run jumper cables to. ST7735 (try getting the exact one as shown in the picture as there are quite a few out there which you may need to flip a line or two in software to make work). An analog joystick with firebutton (lots of breakouts for this, Xbox360 thumbstick spares are the right ones). A ublox 6 or lm80 GPS module. An Arduino feather m0 samd21 dev board.
Hi,
I uploaded a bom to the github a while ago. A friend of mine just built one from the original design and we are making a couple of improvements to it. We are also redoing the feed line trace as he noticed the impedance was not matched. The updated design should be up in a few weeks. I’ve also updated its software this week and testing it, mostly minor bugs, but I’ve updated the survey to show the downlink packet SNR and moved the link check results up to the TX section. I’m going to add in some additional settings to allow the disabling of acknowledged packets (to make it easier to keep inline with TTN’s fair use policy, but to provide normal use with networks that don’t have that restriction), similarly for altering dB transmit levels.
I checked three commercial providers in EU earlier this year and all had limitations on downlink packets. Less strict for some but limitations are there. Usually only a very small number of downlinks is allowed each day. (Some providers even made the 10 packet limit of TTN look very generous)
Indeed. I refer to ‘normal use’ as the fair use policy exists on top of normal duty cycle rules and will vary depending on the network, whereas duty cycle potentially only varies by national region. As the device is primarily intended to survey specific sites to evaluate their suitability for sensor deployments given different conditions, I’ve left ack on by default, so the user can get results ‘there and then’. For mapping or networks like TTN, I would suggest deactivating the acks (hence I’ll add the option in to do it from the gui).
Would so use it!