We are going to be challenged in the coming weeks and months to test and validate the many hundreds of different devices that are used across the Community and will in large part be dependent on users testing and confirming or identifying back (through the Forum?) where possible and more importantly it is in the suppliers interests to quickly confirm if their devices are interoperabe and compatible with V3 - a marketing bullet to promote as well as an insurance measure to stop potential users picking a competing product which does declare compliance and proven interop
(So come on Manufacturers & Suppliers get to it quickly please - your market is waiting )
I’ve just ask to my contact @Ebyte
-are currently sold E78 868LN22S TTN V3 compatible ?
-are currently sold E78 868LN22S flashable (via SWD) with a V3 compatible firmware ?
They may not really have a strong idea of what that means.
In theory LoRaWan compliance (if verified) would suggest it; in practice unless someone has actually run it in the region of interest, it’s hard to be certain.
flashable (via SWD)
In theory ASR6501/ASR602 devices should be… in practice so far I’ve not been able to get SWD to work with my only ASR6501 example (from Heltec) but it’s unclear if that is known pecularities of SWD on the PSOC4, Heltec setting the SWD pins to GPIO to be nasty, or peculiarities of the SWD adapter in relation to the PSOC4 oddities.
Nice to see you were able to get SWD to work on that version of the module.
Curious if you could say which CMSIS-DAP you used?
Have just been trying an Atmel ICE against the Heltec and getting nowhere. My gut suspicion is that Heltec is configuring the pins oddly, but the psoc4 doesn’t seem to support using hardware reset to facilitate connection (nor according to my scope does the adapter drive the reset even when I’ve tried to tell it to).
PSoC4 (and Cortex-M0+ based PSoC4+ ) have not a lot of protection methods supported.
The Ra-07h module comes in “OPEN” state. So debugging is possible over either generic ARM CMSIS-DAP or with Cypress proprietary KitProg2/3/4 probes.
HELTEC keeps no secret that debugging of their modules is possible with KitProg3. Thus, it is likely that the factory setting for the modules is “PROTECTED”.
Status of Ebyte E78 is currently unknown. If they ship the module with “KILL” setting - there is likely no way to connect and flash your own custom firmware into this module. However, if it comes in “PROTECTED” mode - there is a chance to re-use it by device acquisition with KitProg3 followed by “mass erase” instruction.
Should you think that if the old nodes are not compatible with TTN V3. How big a loss it is to the whole system. All existing ones. What installed on the world would no longer work.
I see that this TTN V3 is more of a gateway side problem.
But what are the correct settings for this module on the TTN V3 side.
Hi @jfmateos !
I put aside E78 and more generally TTN in 2021, having not a clear vue of V3 mutation (langage barrier is for me a part of problem ).
I hope a come back to TTN in 2022 with a clear understanding of V3 requirements.
In a pragmatic way 2021 is for me a ‘fall back Sigfox year’ for new connected things (with low cost Wisol SFM10R1 module) , old TTN Things continue to roll until V2 death …
With a brand new TTIG Gateway registered on V3 , I got some successfully tests with some E78 end devices with their original V1.0 firmwares (E78 bought in 2020)
End devices registered with MAC 1.0.2 or MAC 1.03 on V3 Console
Ok for OTAA or ABP E78 end devices
Class A
more tests on the go to observe E78 dealing of download link , MAC commands……
I say ‘it works with V3’ , fully compatible ? that’s to proove !!
Now, did someone try the Ra-07H? I tried both, above repo and their own (GitHub - Ai-Thinker-Open/alios-asr-lora) which is actually a fork from the other (although old), and the module hangs after the initial message… The module comes with pre-loaded firmware which seems to work, but flashing from the repo did not work for me…