Care to try porting to the ASR660?
It’s ARM, has the memory and a TCXO on the LA66 module.
Yes, I understand your concern and appreciate your responsiveness. Let me clarify a few points:
- For experimental purposes, I have been using TTN on a private network, so it does not affect the community version.
- My project application involves too few end devices to go for a full gateway.
- I read your comments on the One Channel Hub forum regarding the difference between ‘One Channel Hub’ and a ‘Single channel packet forwarder’ and realized I had misidentified the device I’m working on. Based on the criteria for a OCH (SX12xx, fixed SF and frequency), I should refer to my device as an One Channel Hub.
- Since I’m still in the development stages, I am using ABP mode for its convenience, which is supported by TTN. I hope this answers the question “Why ABP?”
With that clarified, my questions are:
- Besides undergoing a power cycle, what else could cause a frame counter mismatch between the end device and the server?
- In case of a mismatch, is there a way to automatically detect and reset the frame counter and MAC address?
You can’t use TTN on a private network - it’s all a shared network - please elaborate how your systems don’t interact.
It’s not just the hardware specification, it requires particular firmware so the the LNS knows how to manage it. If you are not running the particular Semtech firmware it is still a SCPF.
The community relies on TTN so you’ll understand that being clear about what is actually being run is rather important. And that clarity will also give us more information about your configuration.
OTAA is just as convenient as ABP and may well resolve your issues - have you tried it?
It’s not actually not TTN. It is The Things Stack open source on my own server.
I have used this git repo to set up my device: SCPF (same hardware is used)
If you check out the link, you’ll see downstream messages are not supported yet. So please let me know how to use OTAA on single frequency without downlink.
Nine days later, some less charitable individuals may conclude that it is now a TTS OS.
You’ve picked the original and oldest implementation of a SCPF that doesn’t do downlinks so your research needs refinement.
Assisting some with a SCPF when there is an official, spec-meeting Single Channel Hub seems pointless. But particularly providing information that can then by used against TTN is defeating the deprecation policy.
If you want to convert your SCPF to a Single Channel Hub, we’ll be happy to assist. But this topic is clearly going no where on a discussion that, like Voldemort, can’t be mentioned.
1 Like
Will you please elaborate on that?
Not sure I can, you’ve linked above to the discussion on the official one channel system - we don’t know what your hardware is for your “gateway” so it’s hard to comment further. But if you run in to problems with the code from GitHub, feel free to ask.
Alternatively as SCPF’s were a ‘thing’ 10 years ago (hence age of the firmware you highlighted) back when GW’s cost $12-1500+ to deploy, now they are <<$120-150 (<<$100?, and even cheaper 2nd hand) so why not get yourself a proper LoRaWAN GW and add to the community deployment and simply turn your (as yet unknown) SX12xx based device into a more useful and productive end node/device and avoid all the hastle and fuss! 
(If on your own TTS Server instance peer with TTN via PacketBroker 
)
@benamiri, Jeff is ever the optimist but reality bites …
It may well be that you don’t have simple access to purchasing a gateway concentrator or a complete gateway.
If you have a moderately sized MCU for your SCPF then it can be used for a One Channel Hub, you may well be able to port the code, but if not, ask questions.
As for peering your TTS OS, if you’ve a One Channel Hub, then there’s no reason not to connect it to TTN. Connecting a TTS OS to Packet Broker requires a considerable number of pre-requisites: Connect | The Things Stack for LoRaWAN