No, this is not right. At least, we have a full LoRaWAN stack as part of the system layer accessible via the Arduino core. Whether this is exactly the same as the Murata stack probably not, since both the ST HAL for the L082 as well as the stock LoRaWAN stack are bare minima.
We are not just grabbing ST’s Arduino core and shoe-horning it into the Murata Module. We have built a system layer from scratch including both L082 and SX1276 system calls supporting all peripherals in a power efficient way and then created an Arduino layer on top of this into an integrated, well-designed whole.
Bottom line, the user will be able to use the 19 GPIOs and associated peripherals of the L082 as well as LoRa p2p and full LoRaWAN with the Arduino IDE as easily as any other device out there, but likely more power efficient and faster…
Indeed great news, really looking forward to it!
I’m a bit confused though by what you mean with:
Is the “stock LoRaWAN stack” the stack from ST that they developed for this Murata module and got the LoRaWAN certification on AFAIK, or the LMIC stack that most people use when developing for Arduino, as that would void the LoRaWAN certification I guess? (BTW I don’t think a “Murata stack” exists as they refer to ST for the software)
Anyhow both the grasshopper and the Lora sensor tile would be great modules for both tinkerers and other developers using the STM development environment.
OK, clarification from my colleague Thomas who is developing the system layer and Arduino core:
"We are using the official Semtech Stack (https://github.com/Lora-net/LoRaMac-node) as a starting point. Reworked the region code to be space efficient. Reworked the radio stack for the same. Totally different porting layer internally from the original stack for power reasons.
ST is using the same stack as a starting point, with their own porting layer, which then goes to the HAL. Lot’s of bugs there …"
Didn’t mean to disparage (too much) SEMTECH’s stack or ST’s HAL but the Grasshopper system layer (including the LoRa/LoRaWAN stack and L082 HAL) and the Arduino core are new, complete, space-efficient, designed for low-power usage, and reasonably bug-free. Of course there will be bugs and we expect the initial users (including ourselves) will help identify them so we can fix them as soon as possible…
Would it not be such that the arduino core would need to specifically be able to select between these regional operating frequencies or else it would just be operating on 868 MHz?
The data sheet of Murata indicates that it should be able to operate between 860-930MHz so using very low level software it looks to be possible.
I assume it’s possible too but coding the channel negotiation protocols for AS923 may not be trivial, otherwise Pycom and Microchip wouldn’t be taking so long.
We can all be thankful we have people like you with a vested interest to put the required effort in
But I think the answer is that at this stage you may well have to program at the ST level. Surely ST would be able to provide you with that level of information. Otherwise the chip is likely to not get much deployment in Australia/New Zealand.
The Arduino core that we will be releasing (mid-January) for the Grasshopper and other CMWX1ZZABZ-embedded devices like our Cricket Asset Tracker and LoRa Sensor Tile (see above) will allow the user to trivially select the frequency band and everything else needed to configure the LoRa radio for point-to-point or LoRaWAN service.
Please do learn how to make use of the tools ST provides for their dev boards, but for Grasshopper et al using the Arduino core will be the easiest, lowest-power, and most efficient method to program the CMWX1ZZABZ for LoRa use.
The on-board pcb antenna of the Grasshopper was specifically designed to be rather wider band than necessary just for US use with the intention of making it usable for people in many locations, including Australia and New Zealand. You can always use a whip antenna or pole antenna using the uFl connector on the board. The on-board chip antenna is well-matched to the 860 - 930 MHz output of the Murata module.
Not sure if this answers whatever question was being posed, but if not please ask again!
Interesting. Do you know if it’s possible for two nodes to communicate point to point to each other and at the same time be part of an open OTAA lorawan connection?
Just an update for this thread (I’ll post a more thorough status report on a new thread in a few days). We made the first tests of the CMWX1ZZABZ Arduino core and our LoRaWAN API and we were able to join and send data to a Multitech AP gateway as well as the TTN via a TTN gateway. Choice of region and sub-band is straightforward and the function syntax is different than but similar to the ttn.h API, i.e, easy to understand and use.
The LoRaWAN API works well and seems robust. We have more testing to do naturally but the Arduino core should be ready for serious use very soon, certainly before end of January.
I have seven of the LoRa Sensor Tiles shown above assembled now that I plan to test as part of a single network using the TTN gateway.
I also expect to start production of the first 100 of these LoRa Sensor tiles this month.
Indeed exciting. Problems I’ve had with the lmic library and the teensy (which doesn’t maintain a clock whilst it’s sleeping) is that it would wakeup on a timer, then wait 13 minutes, send a packet and go to sleep again. However, the 13 minute wait only happened if the sleep (Which was a for loop of sleeps of 50s) was in total for just one hour. The other nodes which did the for loop for 8 hours didn’t have the problem. Nor was there (that I detected) a problem when the node woke up from a gpio, but is likely that I simply didn’t detect a problem.
In any case, I’m hoping that all that will go away as well as requiring one less battery when I can start to use your nodes
Nice one! I have a request. Are you able to put an example there how to correctly handling deepsleep and wakeup on gpio? Also deepsleep and wakeup after a given delay?
Look forward to it.