I’ve replied on other forum
Just to confirm that the payload decoder function (as provided by WASN and used a lot) works as expected after migrating the device to ttn V3, even when the default handler function in v3 did change.
Hi, I’m really struggling with CubeCell devices and OTAA on V3. I have two gateways both on V2. I’m in New Zealand so using AU915 and the AU1 cluster.
I can see the join messages, in the V3 console but the devices never complete the joining process and keep retrying.
I have modified the region settings RegionAU915.h to match the V3 RX delay values.
#define AU915_RECEIVE_DELAY1 5000
#define AU915_RECEIVE_DELAY2 6000After failing with V3, I set the same device up using OTAA in V2, recompiling with the original RX delay values and it connects first time, every time.
I’ve set up an ABP device in V3 with the longer RX delays and it behaves perfectly. So that device, V2 gateway, AU1 cluster, and V3 application are all working as expected.
Has anyone been successful with CubeCell and OTAA with V3, particularly on the AU1 cluster?
Yes I have had success using that combo (cubecell,V2 gateway and V3 application on the AU1 cluster)
I didn’t have to change anything within the cubecell code, but I did have a Multitech Conduit gateway with old firmware setup using kersing’s script which didn’t work passing stuff to V3 until I updated the firmware and then just used the built in packet forwarder (which in the newer Multitech firmware takes only about 1 minute to configure)
Thanks Paul. That’s good news. I was beginning to wonder if the Heltec OTAA implementation was not compatible with V3.
My gateways are both RPi based, one rhf0m301, the other RAK2245. They are both quite old builds. I should try updating one of them. Or perhaps just move one to V3 and see if that fixes it.
We had added all our LoRa boards to TTS devices list and had been accepted. I think the next release will include Heltec LoRa node devices.
5 Likes
Very good! 
1 Like
Hi all, just sharing my experience: managed to get my cubecell HTCC-AB01 working with platformio and the GitHub - LacunaSpace/basicmac: BasicMAC LoRaWAN stack that supports (but is not limited to) Arduino stack, using the pinmap posted here earlier. This works with TTN stack v3. I basically did an “arduino export” of the basicmac code, copied the OTAA example and made some small changes. My changes are: 1) add the pinmap definition, 2) use a non-zero AppEUI 3) use the cubecell internal id as DevEUI.
So I’m completely ignoring the heltec LoRaWAN stack, it looks a bit complicated and fragile IMO. I am already familiar with arduino-lmic stack.
My demo code is here, it joins by OTAA and simply sends a short message at a regular interval:
To try this, you need to install the platformio CLI, then run (for example):
pio run -t upload && pio device monitor
1 Like
Hey Hunter, there’s a small error in at least some (probably all) of the device definitions. When they’re used they use “LoRaWAN Regional Parameters v1.0.2rA”/“PHY V1.0.2 REV A” for the device.
This works fine for ABP on AU915, but I think there are timing differences (or something) and it will not receive the join-accept. Changing it to LoRaWAN Regional Parameters v1.0.2rB makes it work. That was annoying to debug, but an easy fix 
“LoRaWAN Regional Parameters v1.0.2rB” is what you say CubeCell is compliant with on github, so I think this is an oversight.
Can you get the definitions updated please?
2 Likes
Nice work, I believe BasicMac is consolidating still on a different repo but progress hasn’t been rapid.
I don’t think that’s a fair assessment of it, it’s a heavily customised version of LoRaMac-Node which is a compliant stack, and it is stable. It does a lot more behind the scenes than LMIC-based variants and so when it goes wrong that can be annoying to debug, but it’s fairly mature in my experience.
You are an absolute star!!!
I’ve been battling with OTAA in V3 with CubeCell 1/2 AA boards in my spare time for the last 3 weeks or so, and trying to debug the issue. To the point where yesterday I moved a gateway to V3 in case the packet broker was affecting the timings.
One very simple change to the device definition in V3 and I’m getting 1st time immediate joins.
Thank you!!!
Just to chime in - my code for the CubeCell HTCC-AB01 is now also running stable.
What I find best is that I only need a very small solar panel to power it…
How small is very small?
50mm x 30mm, 6V. I have it currently inside at a window with direct sun from 07:00-afternoon.
See my blog for some more details:
(the panel shown in one of the photos is not the small one - this was the first try)
2 Likes
CubeCell 1/2AA boards are a great product, the 3ua sleep is spot on too.
I am trying to build a weather station around an AB02 and don’t want it to go to sleep in between sending to TTN.
Where in the code should I be doing this?
For a quick hack, I tried just commenting out LoRaWAN.sleep in loop, or commenting out devieState = DEVICE_STATE_SLEEP , but neither work
cheers
Paul
edit: have found somewhere that this may work
" You can avoid sleeping, by replacing LoRaWAN.sleep(); with Radio.IrqProcess( ); "
Will give that a go
All good, happy it helped someone else. I’m trying to get Heltec to update their device definitions but not sure they’ve noticed yet. It’s going to bite a few more people until it’s fixed.
Our node devices already exist in the last TTS release.
Looking at the linked conversation:
Hi @Heltec-Aaron-Lee these defs need to move to use RP001-1.0.2-RevB rather than RP001-1.0.2 inside them – using RevA means OTAA doesn’t work (at least for AU915 OTAA). It’s quite frustrating to debug that, works first time when moved to RevB.
@hunter8801 I think that the request is:
Change “RP001-1.0.2” to “RP001-1.0.2-RevB” in the existing device definitions.
The existing device definitions need to be updated.
@bwooce English is not Heltec-Aaron-Lee 's and @hunter8801’s native language. It helps to clearly express in more simple English language what you try to communicate.
1 Like