Been exploring LoRa with a TTN Node (ie effectively the demo one) which has prompted a couple of quick questions.
The node seems to have been transmitting every 34 seconds, whereas I was kind of expecting every 60 secs from:
// Set RN2483 to sleep mode
ttn.sleep(60000);
Where is the 34secs coming from?
Second, the AAA batteries expired after about 5 days, so guessing that it needs a firmware update. Is there any sketch that can be loaded to show the current F/W version - I can’t see the version number in any of reported default parameters. (I know it’s not necessary to know, but I feel more comfortable if I can see what’s going on!)
No-one got any ideas on this? Actually scrub the question on the how to find the current F/W version - I can live with just updating it to eg v1.04 (not sure that v1.05 is necessarily 100% robust?).
But I really would appreciate some help with why the unchanged Basic sketch is messaging at 34 sec intervals rather than the expected 60 secs. (Unless, I guess, the firmware is mis-translating the coded interval into hardware time - maybe the expected clock frequency is wrong or something, but that seems a bit far-fetched and surprised I can’t find a link to any such error.) Suppose the pragmatic solution is to update the firmware and see if that corrects the timing problem as well as the battery drain.
you should check the main program for delays/sleep. The statement you quoted puts the radio module to sleep, however the main program can wake the module whenever it wants.
Search the forum for updated (and more energy efficient) code for the node, it should be somewhere…
Also, check the TTN github repo, there is a sketch in there to get Device information .
There is plenty to be found on the forum already, that might be why people don’t bother replying to your questions as you should be able to find the answers with a simple search…
I had tried the DeviceInfo sketch originally (that’s what I meant in the reference to default parameters, but probably that wasn’t very clear) but it doesn’t report firmware version . It seems to make a call to ttn.showStatus, but I can’t spot which library that’s in - not that it really matters - it does what it does…
And the board is correctly defined as Sparkfun Pro Micro & ATMega32U4 (3.3v 8MHz), hence my confusion.
But I’ll go ahead and try the firmware update, maybe that will fix things?
And sure I take the point about searching for existing threads, but it’s like joining any new area of interest - it takes a while to become familiar with the terminology of the topic (ie exactly what to search for - eg TTN calling their node simply ‘Node’ which is not the most unique of search terms), the structure and MO of the forum and then trying to disentangle development threads from straightforward ‘here’s what you do’ replies. Must say that I’m slightly disappointed that buying a new TTN Node in October 2019 doesn’t already have recent firmware installed, an optimised sketch etc. Isn’t the Node what you’re meant to buy to get some initial easy introduction to how LoRa works?
You could use the PassThrough sketch to interrogate the RN2xx3 module directly with AT commands - or expand upon the DeviceInfo sketch to do that - the command is ‘sys get ver’ - but my Node is with a client right now so I can’t test that.
I understand your pain on the firmware - it causes additional support issues. As a small scale manufacturer, I can release very up to date modules - but if I go and have 1,000 made of something, they are always going to be shipped with the code base on the date they were made - unboxing, updating and putting them back isn’t economic and neither are small batch runs.
At the UK conference Wienke said we had a world wide shortage of those that can code & understand the electronics so I asked him about having some consolidation of the training materials - he’s settled on the resources provided so the initiative will have to come from the community at large. Finding the right answers has become laborious with the blizzard of Google hits, PDF’s, white papers, academic papers and a multitude of products - I’ve certainly disappeared down the rabbit hole many times.
But to continue the debug in the meanwhile, you could setup an onInterval handler that prints the millis to the serial port and turn on the timestamp in the Arduino IDE monitor so you can get some hard data - see if the increment of the millis is keeping tabs with the timestamp.
Or really mess with the codebase’s head by putting a 100ms delay in to the main loop along with a print to serial.
The node->loop(); API ref says that if you have anything on USB, it won’t sleep ie, will continue at full power. You can override this with void configUSB(bool deepSleep); This may solve the battery issue.
@descartes: Thanks for the further comments and an update:
I’ve updated the firmware to v1.0.4, which prompts two comments:
Using the Microchip LoRa Development utility for updating the F/W (and once I’d found my way around the UI) does show the existing F/W version (which was v1.0.3).
After the update, the message interval from the TTN node is around 64secs, which is in the right ballpark now. Not sure exactly where the extra 4 secs or so comes from, but no big deal. More importantly, it does look like there was something in the 103 F/W which was causing the short message period. I don’t know yet whether this has fixed the short battery life; maybe I will need to move to the low power sketch mentioned upthread, but one change at a time! (My test Node is not USB-connected.)
And yes I’d echo the comment on the fragmentation of support material. I rather naively thought that the elegant front-end to the TTN website and the apparently well-structured Learn area meant that all the necessary information to get properly up and running would be there, but I now see that was a mistake…Maybe the biggest criticism is that the Troubleshooting section for each hardware device is (very?) incomplete. Even a set of links added there to various other support issues (that are documented elsewhere but not linked) like how to update the firmware would be a step forwards.
As it happens I spent a coffee break reading the Arduino library source and couldn’t find anything obvious about timing in the Basic code - the ttn.sleep function puts the radio to sleep for Xms, it’s not a transmission schedule, which has been hard coded at 60s on line 56 of the .ino with no trace of a comment!
As an elder geek with many client development teams, I’m slowly losing the will to live - if only GitHub had some reward mechanism for including documentation …
If only people asking questions would link to the specific code they are asking a question about . (and in a way where it can be examined without installing it via the Arduino IDE)
The code that is there would seem to use Arduino delay() - something that is very much dependent on building with a correct CPU clock. However, having the CPU clock wrong would also make the baud rate wrong - which is not an issue PC side if you are using a 32u4 where there isn’t really a baud rate there. It would be an issue in talking to the RN2483, unless the RN2483 does autobaud and would adjust to the factor of two difference from the intended baud rate?
Maybe some context would be helpful: I am not a developer (or at least only in a passing, very amateur way) and have only a vague acquaintance with Github. Maybe I shouldn’t be here, but it’s tricky to know where else to look for information & advice.
My business is one of the main UK dealers in mid-price automatic weather stations, including stations often located at remote sites and currently uploading data via the cell network. We know a lot about weather stations, sensors, what data handling options and platforms are available and so on, plus how to bring all these parts together to create solutions for end-users. But we are not hardware developers and only occasionally get involved in software development.
We can see the potential for LoRa/LoRaWAN in principle and especially in driving down costs for remote stations, but while there’s plenty of proof of concept demonstrations for weather applications, there’s relatively little kit that I can find that uses professional (or even prosumer) quality weather sensors. It’s also not a market where large development budgets can be justified - the RoC is just not there. So we have to try to make our own assessments of how viable any potential new solutions might be and that’s all I’m doing here - just dipping an initial toe in the water by looking first at what appeared to be the easiest option, ie the TTN Node and just getting an idea of exactly how that works.
(Actually the preliminary conclusion is that the hardware seems to work reasonably well, albeit with wrinkles, as does the TTN network. But the limiting aspect might well be the availability of a cost-effective cloud dashboard for end-user display/analysis - the examples I’ve seen so far may be good technically but disproportionately expensive relative to the cost of the LoRa hardware. But this aspect obviously needs exploring further.)
To answer the question about the code for the Basic sketch: That’s in the Examples library for TTN Node in the IDE. I have no idea why it’s not on Github nor about anywhere else that it might be available online. Sorry.
And therein lies the challenge - you have to install two TTN libraries - which makes for some cross-referencing to be done whilst reading the source:
is where the Basic is at but as I mentioned, it has a hard coded un-commented magic number for the transmit duty cycle.
I’m not sure we’ll get to find out what happened to @prodata’s node but his experience reflects the support issues my clients have getting started, hence the suggestion I made to Wienke.
The marketing line is anyone can dive in and use the starter materials, which is exactly what happened to you. The commercial hope is you decide early on that the out-the-box experience has potential and then commission a proof-of-concept or pilot. The first round mass market implementations in areas such as energy metering or cold supply chain monitoring or some such came with projected cost savings that justified corporate development teams which usually comes with a code base that’s as much an art installation as it is computer science when really, it should be software development - the Semtech code base being a perfect example - yes, it’s open source, but you really need some consultancy time to get to grips with it plus a MPU with bags of RAM. Whereas others have written much more pragmatic implementations that fit on entry level devices.
Reality is that you have to know stuff that your average developer isn’t going to have ever due to the intersection of hardware & software, hence the shortage. It’s only 30 years experience that allows me to navigate this treasure island, see where the bear traps are and figure out where the gold may be buried.
The common problem with a early adopter community is that it is all too easy to forget what you learn’t to get to where you are now. And because the learning was rather experimental, the forum entries aren’t well formatted in terms of phrasing.
Dashboards are a commodity item now with plenty of toolkits for web developers to build. Someone with hardware experience can link your weather sensors to some LoRaWAN enabled device and possibly get the data to a place that the web peeps can pull it down to the dashboard.
I’m remote, in the High Peak, looking at rural use cases, including ground state as when it rains hard after a few drys day, floods occur. Whilst I get a data feed from a Davis station which I turn in to a dashboard for my fellow glider pilots, we are also looking at distributing some monitoring nodes around the area to build a more comprehensive data picture.
@descartes: Appreciate I’m wandering OT here, but let me just clarify the dashboard point: Yes, I appreciate that there are 1001 dashboard tools out there. I’ve got a primitive one I put together myself in Node Red for looking at my LoRa data as a starter. But what I’m really thinking of is something that could be commercialised but at an affordable cost and that would cover the following bases:
Reliability: Selling products to eg farmers who then come to rely upon its data will only work if the platform has excellent up-time and general reliability; Attractive, fully-featured UI: Something like the Davis weatherlink.com platform or the Sencrop (SigFox-driven) one are examples, but these are both in-house developments ~(albeit using commercial hardware platforms); Scalability The architecture needs to be intrinsically multi-user and scalable, Davis currently support 30,000 users, Sencrop say 8000. But it needs to be able to start off small (say 20-50 users initially) to be affordable and gain experience; Durability The platform has to have legs and there must be some excellent prospect of it still being around in eg 10 years’ time; Affordability:Really the crunch factor. There’s got to be some workable business model that can develop and then maintain and support the dashboard/backend-database platform without requiring a 6-figure investment upfront. One appeal of LoRa sensors is that the hardware cost is low (relative to mobile data feeds) but ongoing costs (eg annual subscriptions, mostly to support the data platform) need to be relatively low too. It can’t be free - that wouldn’t make sense, at least not after any introductory period - but something like £50pa (maybe per site) is what feels near the maximum to me.
It’s trying to pull all of these factors together into a workable and cost-effective package that feels to me like the biggest hurdle to using LoRa more widely in my sort of applications.
I’d not recommend people make changes to a library unless they’ve already suffered the pain of making a change and then having it bite them on the bottom on a subsequent project. In this instance, and so anyone searching on the forum knows, this is where to set it in the .ino:
Definitely OT, perhaps time to start another thread but from my experience, this is all doable and is likely to appear over the next few years as the next wave of adopters start investigating. Maybe I should write WordPress for Data …
I sent you a message with my contact details if you want to pick the conversation - having access to proper weather sensors wouldn’t do me any harm at all. IGNORE this, caught up with the inbox
. It seems to make a call to ttn.showStatus, but I can’t spot which library that’s in - not that it really matters - it does what it does…
. (and in a way where it can be examined without installing it via the Arduino IDE)