@arjanvanb You are absolutely right. According to the schematics, the Microchip gateway uses either a TA0547A or a TA1561A SAW filter. The former has a center frequency of 867.5 MHz, while the later 915 MHz. Both have a relatively high bandwidth (860 MHz to 867 MHz for the TA0547A and 902 MHz to 928 MHz for the TA1561A) meaning that within these bandwidths, everything is possible… If anyone is interested, the specifications for the SAW filters are online: https://www.taisaw.com/upload/product/TA0547A%20_Rev.1.0_.pdf and https://www.taisaw.com/upload/product/TA1561A%20_Rev.1.0_.pdf
2 Likes
@JDP Now I see, I misinterpreted your post! Sorry for the dumb reply, you are right, most probably you could do the modifications in the source code. Sorry again!
1 Like
It seems that the registration process of the TTN Gateways makes a difference in the public visibility. I checked “Recumbent Travellings” gateway and see that instead of eui there is an alias. I would also prefer to hide (or obfuscate) the eui. This would help changing Hardware with same name. 
The TTN protocol does not use the EUI, it uses the gateway (short) name in stead. When using the semtech protocol you will still be using (and showing) the EUI.
If you ‘upgrade’ your packet forwarder to either the TTN packet forwarder or to MP forwarder you’ll be using the names as it uses the TTN protocol.
My ttn-gateway is still not working and the only use for it I found so far is to compliment the christmas decorations since the flashing green leds fit pretty well in the christmastree. I captured a lot of uart logging but since there is no documentation or sourcecode available at this point it’is hard to see what wrong. However I see a pattern. After a couple of initial startups the gateway gets in a loop where it keeps booting, but just before it reboots I see the following in the log:
CNFG: Configuring LoRa module
LORA: Changing state from 2 to 4
LORA: Starting reconfiguration
Does anyone here know what this means and if rebooting is normal at this point?
The Reboot reason is : 0x53 is there someone that has a list of reboot reasons. (would be a nice list for the faq)
2 Likes
Hi @Leondegeling, I saw the debug log you sent us and notified our team about it. I’ll ping them again to see if they found anything.
As for the source code, our colleagues are also working on getting the source code ready for open source, as @wienkegiezeman said in a different topic:
I’ll see if I can get that list of reboot reasons.
Acording to gateway board specification:
Frequency Band - LG9271 902.000 MHz to 928.000 MHz
Frequency Band - LG8271 863.000 MHz to 870.000 MHz
I think IN865 channel plan is covered by the 868 gateway.
Thanks for the link Nestor. I’d seen that the hardware covers it, the question was more about how deep I’d need to go in software to enable it. I.e.
Option A - existing software will cover it, via changed config settings
Option B - would need to modify source and rebuild new image
Opt A would be available immediately, opt B would depend on the discussions above about availability of the open source.
I look forward to finding out
Thanks
You can change the frequency plan of your gateway in the console. The next time the gateway restarts it will use the new frequency plan. Future frequency plans will be added to https://github.com/TheThingsNetwork/gateway-conf/ after which they can be selected and installed on the gateways.
1 Like
Hello Folks, with the help of people of the core team I just now managed to connect my gateway to TTN. The lora board seemed to be well in place but I found that with a little force I could wiggle it around slightly and push it in just a bit further. After powering up it registered with TTN and now the console says the gateway is connected. I can’t wait for my first message. Thanks everyone for the support.
8 Likes
FedEx shipped package arrived today
unpacked - connected - setup - running
b.t.w. the black backside should be covered later at my sunny place otherwise the things will melt 
9 Likes
i’m in a bootloop as well. all leds flashing. tried all resets, except full serial wipe. ether & wifi tried. farnell.
Did you try what seems to have worked for Leondegeling: “The lora board seemed to be well in place but I found that with a little force I could wiggle it around slightly and push it in just a bit further.” ?
yes. did not budge.
Big thanks to everyone who worked on this in the past 2 years.
Fedex delivered my Gateway today; no problems at all to get it up and running.
Node took me some extra work; till I decided to grab a Laptop and not try and do it on an old 2008Server
it now pings it’s 24.88 Celcuis here… good argument to get me a cold beer.
6 Likes
i did remove the radioboard from the struts and pulled it out and pushed it in again. no improvement.
i changed the firmware update setting from yes to no in the console. no improvement.
removed the gateway registration in the console, and tried it all over, no improvment
after ‘waiting for gateway xxxxx to check in…’ on led 3 slow flashing, all blue leds lit. then gpio 1 on radiocard turns on, off, all leds off except 1 near powerinlet, all blues and gpio 1 turn on … ad infinitum.
Thanks for the updates… As someone anticipating getting a shipping notice some day soon, I’m eager to know solutions for the type of problem you’re encountering and hope that the core team will be in touch with you shortly to attempt a solution, if that hasn’t commenced already. Will be grateful to know details if and when a solution is found.
1 Like
My gateway did the exactly the same thing.
I then connected my sparkfun basic breakout module to read the debugging output from the uart. In the output I found that the reboot occurred when the gateway was reconfiguring the lora-card.
Then Marten wrote:
In my case applying some force was the solution, in your case the loraboard might be bad.
I would try to readout the uart debugging and determine at what step the device reboots, that does greatly improve pinpointing the cause of the problem. (see description in faq). If you need help doing this, let me know.
2 Likes