Here is the reality. A nice LoRaWAN board costs between $40 and $99 (the ST GNSS variant). If you go cheap via e-bay you can get something for $20 (but not with GNSS and other goodies). So it’s really $20 vs. $40.
How much time do you kill with the $20 board to get things not working ? I do value a hour of uninterrupted time (may it be to play with electronics or going riding my road bike) for me at way more than $20 …
N.b. “BluePill” is cheap precisely because it’s obsolete …
It’s up to decide for everyone themselves what they want to pay for a (basic) LoRaWAN node and this thread is not the place to discuss that. There are enough people interested in TTN and LoRaWAN that are not willing to pay a few hundred bucks for a hand full of nodes only to get familar with the technology or experiment with nodes for their hobby.
A muRata based LoRaWAN board on eBay for $20? Do you have some links?
I would concur with @bluejedi, we all have different views on the reality, i.e. the value of our time.
There is no right or wrong here.
And there is nothing wrong with folks picking their solution. My point is just that I have a problem understanding why somebody would want to save a few dollars (or euros) on the hardware, and then getting stuck with a non-functional setup due to the software.
I did not state there is a $20 Murata based board out there (actually, I have no clue). I just quickly looked up what the cheapest other LoRaWAN capabable board was, including shipping. The Murata based ones are all around $40, give or take.
Please also understand that my interest is really to experiment with low-power devices. I do not get a kickback from Murata or such. It just turns out to be the sweat spot, everything considered.
Yes, that was exactly my point.
Following this, greetings!
Thijs, The Netherlands.
FYI
https://stm32duino.com/viewtopic.php?f=16&t=4671
By RogerClark:
Some of you may have read the post by @fpiSTM:Thanks for your time and effort, Roger and contributors.
The stm32duino site is a wonderful place to come and visit where you can enjoy loads of tips and tricks for prototyping.
Following Roger’s proposal, STM will make sure that the information that everyone has contributed will not accidentally get lost.
The content of the stm32duino.com site will be transferred on a new server in H2’19, and hosting and maintenance will be handled by STM using the same address name.
This move aims at providing a very convenient place with independent moderation to our community of passionate members.I have been in discussion with Frederic and STM for several months about the future of the forum, and I will be transferring the ownership of the domain name and the forum to ST. The hosting will move to their servers, and I will no longer be the administrator after the transfer.
Because the site now has a future under ST, I have re-enabled new user registration.At the moment the technical and other details of how the site can be transferred needs to be determined. Private information about users like their email address and password etc, can’t be transferred without the permission of each individual user.
I’m whether the publicly visible username can be transferred either. As this is not private information, its probably a grey area, but unless public usernames can be transferred, everyone would have to re-register under new user names.
I’m hoping that this won’t be necessary, and that I can setup a temporary authentication system on my server, where the new server can request my server to send a re-validation email to a user when they first need to login to the new server.
This would be where user need to agree to the new Terms and Conditions, which will be required. However, quite how this would work needs to be determined.
I’d like to thank Frederic and the other guys at ST for their work in-house with this entire process.
By fpiSTM:
Don’t worry, there will be no change.
In fact only the hosting will change not the way the forum live. Moderator will be the same if they want. No ST dedicated moderator except me.
Nice but I’m surprised to see a bulky male USB type A connector instead of a compact female USB type C connector.
This not only makes it bulky but also much less flexible to put in an enclosure.
Heat shrink tube is not what I would call an enclosure (and may negatively impact cooling).
“Cooling” ? For 40-80 mW device … Kidding ?
Covering with heat shrink tube impacts cooling in general, hence the ‘may’ (not knowing all details of the board and its components, e.g. when powered via USB).
Yes, USB C Port would make extremely sense for this device. Best way to break it by leverage and when you want to use it with a raspberry you are happy as well…all your arguments makes no sense to me.
USB Type C Female, that is the one that you connect with a USB C male to USB A male cable.
The USB-C male cable connector is easy to insert and remove and can even be inserted upside down. And when the cable is not inserted the device can be significantly more compact (when preferred).
But of course different people will have different preferences.
Apparently you have different preferences.
With a bluepill board (STM32F103C8T6, 128k) I am unable to get MCCI LMIC library working.
IDE: PlatformIO, board = bluepill_f103c8_128k
LMIC libraries:
Sketch: ttn-otaa.ino included with above MCCI LMIC library.
Modifications to sketch:
(Switching between both LMIC libraries can be done simply by specifying the corresponding library dependency in the platformio.ini project configuration file.)
When using the LMIC-Arduino library the example works fine (uplinks and downlinks) and does not even require ClockError to be set.
When using the MCCI LoRaWAN LMIC library evrything appears to hang after the first EV_TXSTART event (while it attempts to join).
After the initial join request no subsequent join (retry) requests are made (not visible on TTN Console). Normally, when the first join request fails (e.g. because of timing related downlink issues) a subsequent join request will be made within minutes. This is however not the case and the node appears to be hanging (waiting indefinitely, or crashed).
And in both cases you use the Arduino Core STM32? I am not too familiar with Arduino, especially on STM32. So I am not of much help at this point. But if I find the time I could have a look into it.
Or did you copy my port of the mcci lmic to CubeMX generated code + LL drivers? In that case there might be some changes necessary from STM32L071 to F103.
Yes
No, I am using the vanilla (unmodified) versions of both libraries.
Okay. When I find the time and manage to attach a debugger while using Arduino, I could have a look into this.
