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?
Kim
I don’t know.
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.
Very exciting!
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
Kim
The Teensy 3.2 is a great development platform but not for low power.
Here is the github repository I am loading with sketches as I test them. Still plenty of work to do but you can see we are getting closer…
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?
Kim
We have STM32L0.sleep();, STM32L0.stop(); and STM32L0.standby(); as power management tools.
For timeout in milliseconds, I would use:
STM32L0.stop(timeout);
at the end of the main loop in your Arduino sketch. This will periodically (every timeout/1000 seconds) run whatever is in your loop and then the MCU will enter ~2 uA stop mode.
When managing sensors I usually use:
STM32L0.stop();
this will wake from stop on any interrupt or communication request (UART, etc) and you can easily set up an interrupt from a GPIO, etc.
The power modes are similar on the L4 and there is some more detail here:
Guys I would just like to chime in here. Received my Tile today and had it sending data to TTN within an hour including setting up the Core with Arduino and modifying some example code!!
OTAA join was blazing fast compared to what I have been working with so far and everything just worked!
All I can say is that I am impressed.
Serge
@onehorse
I found a lot of Arduino repo for STM, would you mind provide a link for the one you use with you board? I don’t see it and how to install. may be worth having quick setup Arduino (or other) to compile and use your awesome boards 
Thanks
Just quickly, the B-L072Z-LRWAN1 board is also supported by the Arduino core. In case anybody has one around and wants to play.
Great! I will have a look at it soon. Thanks!
That was smooth! Got it up and running in less than 30 minutes. Very smooth. I will certainly work more with your software the next weeks and will give you guys an update at some point.
Thanks!
David
I second that.
I have three of these devices in the field working for several weeks now. I found one bug initially which was fixed quickly within a day, now it’s stable as a rock. They spend almost all their time in deep sleep and the timing delays to wakeups are pretty accurate.
It’s nice also that they run on 2x batteries instead of three for boards that require 3.7v. I’ll be deploying several more of these of the coming weeks.