I’m using Feather M0 with lora 900mhz. It worked perfectly for a month or so, but all of a sudden, it said ‘USB port not recognized’. I tried to do the troubleshooting by resetting the feather, updating the drivers, etc., but no luck.
I decided that I’ll buy two more feathers to keep my work going. Two brand new feathers were procured from Mouser, and to my surprise, the same error shows up when I connected them to my laptop. I’m completely shattered now, it’s not just money but considerable time has been invested into it. May I know what’s happening here. I’m just reconsidering other platforms for building my LoRaWAN endnode. Can you suggest alternatives for the feather M0!
One thing I’ve realized over the past couple of months is that Device is the bottleneck in LoRaWAN system. I’ve built gateway in no time (with the help of TTN community) and the integration with platform/SDK was straightforward, and the backend and front end was configured with not much of effort, but establishing communication between device and gateway has been a very painful process. The feather was arrived at, after experimenting various configurations, and I am really upset to see this sort of problem arising at this stage. I wish endnode device configuration too were very simple/straightforward as incase of gateway.
Sounds like the problem may be with your PC. Try an different PC.
FYI, I do a lot of embedded system development and do not use the embedded USB capability of the processors. Instead I use an async serial port on the processor and a very cheap (aliexpress) serial to USB adapter module to provide the USB interface upstream. The USB module is power by the host computer and not by the embedded system. This eliminates all sorts of USB related issues.
I’ve done that, posted the query on Adafruit forum. My question was not about just feather, but about the ease of use, and reliability of the endnode for a given application. In terms of ease of use, feather was superb, but when it comes to reliability, it is not so (I’m making this statement from my limited experience). So I’d like to learn from the developers on TTN forum, about the hardware platform for the endnode, which fulfills both criteria mentioned above.
The USB problem you seem to be having really isn’t a LoRa or TTN problem, but a PC or embedded device one. In addition to the USB UART mentioned, you should get an SWD adapter so that you can program the feather’s processor without relying on the USB to be operable.
In terms of the role of a device in a LoRaWAN network, most issues are software issues not hardware issues. Adafruit does not really maintain a LoRaWAN stack for the feather. The applicable thing would probably be MCCI’s branch of Arduino LMiC, which is actively maintained with the feather being one of the primary platforms.
LoRaWAN is a far more complicated protocol than most realize (probably more complicated than it needs to be for most uses…) and if you watch the issues list, edge cases keep being discovered where the code doesn’t do what it really should, albeit mostly in situations that don’t happen in the real world.
Ironically, some of the things that do happen in the real world don’t get a lot of attention.
Thank you very much for your detailed post, it was enlightening!
Its true, but don’t you think that the embedded system and the software issues are still a part of the LoRaWAN system (from a systems point of view)! Until and unless these issues are sorted, we can’t make the LoRaWAN system work.
Do you mean to say that we can still make these feather boards work using the SWD adapter?
This is mostly a problem for hobbyists and tinkerers, which are not the main target of LoRaWAN, although they are part of because of the open nature of LoRaWAN. Industrially produced nodes do not use Arduino, as well as they do not use breadboards, etc, and they generally work well.
I’m also looking for a reliable ‘industrially produced node’ which can help to build my application. Can you please suggest one, the only requirement I’ve is that it should support Arduino IDE.
There is no such device as industrial users stay well away from Arduino IDE and use professional development environments (which usually are expensive)
While there is some truth there, to be clear, Arduino is a software environment. Plenty of devices to which it has been ported default to more professional development options. The issue is the software approach with its basis in poor documentation and unclear, nonstandard behavior that ends up complicating in a misguided attempt to simplify, not the hardware platform.
For example, there’s an Arduino port for the STM32L07x (or the SAMD21’s) but there are also plenty of native LoRaWAN projects for it.
Free tools have increasing penetration in professional markets. Others just can’t compete when their attempt to maintain control inherently imposes so many roadblocks to modern software development practices. Situations where anyone in the team (or the build bot) can’t check out the code and build it on any machine because they need a compiler “license” are no longer tenable.
While this statement may be true in general, the reality is the Auduino platform, from a software perspective, is a platform for hobbyists. Anyone trying to build a serious product using the platform is plagued with many challenges. The Arduino IDE is virtually useless when it comes to debugging application - it has no capability of supporting real time debugging tools such as ICE (In Circuit Emulators), no way to perform single stepping, real-time variable read/modify/write, application profiling, run/stop etc etc.
The libraries themselves are the arduino’s greatest strength and its greatest weakness. Greatest strength because of the contribution from a large eco system spanning manufacturers to hobbyists. It is it’s greatest weakness is because a lot of libraries are written by people that just wanted something quick and simple. As a consequence a large selection of libraries lack any type of error detection and recovery and the implementation of library functions are inconsistent. For example, some libraries are hard coded to only work with hardware serial ports and others only with software ports. Some using the serial port functions directly whereas others use stream.
Using the Arduino platform to develop large or complex application is very time consuming and very very expensive. This is why for this class of applications, industrial users do not use the Arduino IDE and spend a lot of time rewriting libraries.
I think the Arduino platform is great for building simple proof of concepts.
You seem to have missed that I was not talking about the Arduino platform, but rather about the hardware to which it has been ported and the free compilers it happens to use… when those are not used for Arduino
The original comment by kersing that your responded to was specifically referencing the Arduino IDE
There are superior IDEs for developing Arduino projects that addresses many of the problems associated with the Arduino IDE. These IDEs are free and use the same free compiler toolchain
These IDEs however do not solve the library problem
First it is mistaken to confuse the identification of a “device” with the Arduino approach. That is not even valid on an Arduino-branded ATmega328p board, and certainly not valid on the sorts of boards that are sensible for LoRaWAN.
Next, be careful not to confuse libraries, toy IDE’s and toolchains, as in reality they are quite different. Yes, anything that uses the Arduino libraries and software architecture is going to be quite awkward.
But no, there are plenty of professional options which use the same free toolchains that Arduino does while entirely avoiding those poorly thought out software APIs and goofy pre-build munging. Last I checked the official offerings for the ex-atmel line were all using avr-gcc and arm-gcc, same as Arduino does, and same as an increasing market share of modern professional projects that are independent of both do.
Because pay-for-license compilers are no longer compatible with modern software development practices.
Practically, what it all means is that there’s room to start off naively with an Arduino approach and later (when there is funding and skilled resources) upgrade to professional methods, all while keeping the same hardware.
I agree with you to a large extend however I do not with this one:
I do a lot of development with PIC micro-controllers and use the free manufacture’s IDE, compilers and supplied libraries. I also pay another vendor for their PIC compilers and libraries. I can develop a project from scratch with this paid-for-compiler environment in 50% to 70% of the time taken to develop the identical project on the manufacture’s tool-chain. I have proved this time and time again on my own products because I sell variants of the same software products for each of these environments.
Bottom line, it is far more profitable for me when I develop with the pay-for-license tool-chains.
That’s pretty much irrelevant. In reality today, software cost is about maintenance and reproducibility, not initial run-ahead-of-the-team development - that’s where just about all of the improvement from the dark ages has been realized.
Only having select machines in the hands of select people which have a license to build the code is no longer acceptable to real projects. And “embedded” is no longer an excuse to break the rules of sound software practice.
I’ve developed on the Feather M0 and I don’t use USB. As soon as you start putting the micro to sleep (uA ranges) the USB will fall over because the PC is not getting any responses.
I use the UART for debugging output and have a long delay after reset before going to sleep that allows me to upload code over the USB if I need to.
This topic has started with hardware issue. However, most of talks are dedicated to software. And “conclusion” was that “Arduino IDE is guilty for everything…”
In reality, the Feather M0 device mentioned by topic starter has badly designed USB connection circuit:
That has little likelihood of being an issue, especially as this is only a full-speed device.
Rather problems are typically the USB code in the chip not being actually running, as already explained. Also mentioned were strategies to work around the USB entirely.
