I have tested FSK in general quite a lot …
For a given distance, LoRa can transmit at a much higher data rate than FSK can, FSK needs to operate a fair few dB above noise level whilst LoRa operates a fair few dB below noise level.
So the FSK mode would use far more air time, and thus more of the fair access limit, than LoRa would.
(position to GW) not easy. But I think doable. Pre-configured and with downlinks.
(GPS fix) Yes, it’s overkill. The purpose is to understand that the device is on “difficult” area.
6 bytes are for Lat/Lon, all other information are stored in one byte (bits) and on ports. The next most efficient is to have less accuracy on GPS or to send difference (meters + heading) or to send relative to predefined area.
Yes, you have right, with different SF’s you can send more (or less) bytes. But this is not on my priority list. With 7 bytes I am ok. My Blind ADR version is on my priority and the MAC downlinks commands with SlimLora. 
@LoRaTracker Thanks about the info. I had the impression that FSK was faster than SF7.
Be careful remember under TTN FUP downlinks are even more constrained - 10 per day - and that includes e.g. join process…and even that 10 should be used only sparingly as the cost to the network and all users in range of that GW is huge as the GW is deaf to uplinks during the downlink Tx 
1 persons node doing a downlink might impact hundres or thousands of nodes doing an uplink (irrespective of SF…)
WRT FSK, yes device is technically capable of much faster FSK operation, and supports that for legacy interop deployments, however, as @LoRaTracker points out the real word conditions typically found in RF environments often mean that that advantage cannot be fully realised and LoRa at slower rate can be more effective due to the SNR issue - you really need to be right on top of the GW and in a low noise env to get advantage. Classically, most tests will tell you that fsk receivers typically need around a 7-10db positive SNR to allow reliable, consistent, discrimination and detection, I think I recall seeing one or two best in class in the 4-8db range, but constraints are tight. LoRa, even at SF7 is capabable of extracting useable symbols down to around -7- -7.5db SNR, so a mighty 14-17db headroom advantage allowing much more reliable extraction and range, hence LoRa being a Long Range solution 
SF12 of course is good to down around -20db 
With each intervening SF step giving approx 2.5db coding gain over the prior SF - giving atleast a 50%+ increase in range (if not closer to doubling FSL range).
It can be, sometimes.
For a given data rate LoRa will cover around 10 times the distance however.
And in addition for a given distance, LoRa can normally operate at a much faster rate then FSK can.
@Jeff-UK really helpful your detailed answer. @LoRaTracker + @Jeff-UK close to GW it’s better with FSK? This is on the limit for FSK?
LORA","datr":"SF10BW125","codr":"4/5","lsnr":7.8,"rssi":-85
LORA","datr":"SF9BW125","codr":"4/5","lsnr":9.8,"rssi":-76
a1) Those are known to me. The GW’s are not so often go up and down. Once per month (?) is not a problem when you configure a device to transmit less. Mind you this is a manual / local process not automated. I suppose my idea is not suitable to cover a country. a2) You / TTN can transmit on low traffic hours.
b) In my surprise TTN sends many downlinks. They are more verbose than me 
I never asked for downlinks, but TTN keeps sending. (TinyLoRa-gate)
Take it out of area at 100km/h and within minutes you’re backend will have to know a lot of information about the regions gateways - if any - and hit that happy moment when an uplink comes in near a gateway you have in range.
I was pointing out that you had a fix yes/no flag as well as a “quality of GPS” field. But as for “difficult” area - if a GPS runs out of its ephemeris (valid for 30 minutes, then warm fixes only) then it’s going to be very difficult for a rather long time unless you let the module run for a minute to update so it can hot fixes for the next 30 minutes.
What does any of this mean - one downlink a month?
No such thing and even if there was how are those going to be determined for an area?
That would be other members of the community that don’t know about or care about the FUP making - its not TTN deciding to downlink - it’s the users.
What is this precisely - from its name it looks horribly like it may be a Single Channel Packet Forwarder.
You seem to be talking one minute about active tracking with a standing/fallen flag and then the next about sending one positional fix per month (or so it seems). Like many of these aspirational designs, it’s so much easier to come up with a design if you provide some context - ie, you tell us what you are actually trying to achieve, then we can be rather more supportive.
Indeed, +1.
Or is this perhaps one of the crippled/incomplete node lora(not)wan implementations much discussed and debated since V3 transition where device then incapable of correctly handling/responding to Network generated MAC commands etc. Such that backend then has to keep trying effectively spamming itself? 
Why does that not sound good where for the application to be viable there would need to be a great number of gateways in an area ?
What’s your ideas about the Blind ADR on GPS trackers? You have something better instead of my idea? You prefer the trackers to transmit on one SF instead of dynamically changing the power and SF?
@Descartes, I don’t get what you gain with your question about my payload. I use 6 bytes for Lat/Lon. One nibble for speed and the rest byte (nibble) for the heading. Total 7 bytes for 5 data (+battery, +stand/fall, GPS qual, GPS fix). Data on parenthesis are bits on the port (zero [0] bytes]. Why you are still asking about my payload? It’s irrelevant. One commercial solution is using 11 bytes for 4 data and CayenneLPP uses 11 bytes only for the Lat/Lon.
One downlink per month (my guess) and uplinks only on movement. Maybe zero per month.
I wrote about an idea that can help all payloads and all LoRaWAN implementations, like LMIC, Tiny/SlimLoRa, commercial solutions. Semtech is proposing something like that with the name Blind ADR.
@LoRaTracker, sorry i don’t get your question.
Personally, I’d prefer trackers to have a definite purpose but yet we all still have no clue what you are trying to create. As for blind/fixed/dynamic, in the right use case any one, or combo or all three have value.
If you don’t like the feedback, don’t post detail.
Just because there are other worse solutions around doesn’t make yours better.
One downlink to what end? Sending locations of gateways as suggested above. And as for uplinks maybe zero, how does that fit with the implications of a flag for standing/fallen.
I’m a bit lost, which idea? The whole “LoRaWAN for tracking” comes up every few months.
The only help for TinyLoRa is for migration away from it - it just doesn’t work well with v3. SlimLoRa, which I volunteered to assist in working on, was sort of announced Feb this year as a potential replacement for TinyLoRa and then the developer has been seen once since. I’m assuming you are using ABP because as far as I know OTAA isn’t working yet, which isn’t great for v3 use.
I’m not aware of Semtech proposing something with the name Blind ADR - mostly because it’s a phrase in general use and partly because their geo-location efforts seem to involve a new chipset plus upgraded gateways.
As for the LoRaTracker question, I asked it too - what is a TinyLoRa-gate??
No one is trying to rain on your parade to dampen your enthusiasm. If you have a specific use case for tracking that you can detail your plans for creating a solution that you want reviewing, we’ll all be happy to help. But at present you have ideas that some of us have seen discussed several times before, apparently no real-world attempts or experiments and a forum with a whole history of people struggling with trackers in general.
@descartes I just try to help the OP.
You have a better idea than mine? You can help me to fit Lat/Lon data in less than 6 bytes? I think this is the only drawback of my payload. (out-of-topic, but since you want to help: I am watching).
My idea is to store GW locations so the device can operate in “White Zones” (my version of Blind ADR for non optimal areas).
I really still don’t get why you want specifics from me. I think my idea is fine for those trackers. They are suitable for assets e.t.c. as @nashenden stated.
I wrote my idea of “White Zones” (for starters GW position is more easy) as a companion to Blind ADR. Something to elaborate on that?
TinyLoRa-gate is my expression like Diesel-Gate, Water-Gate for MAC commands avalanche in V3 e.t.c.
??? Downlink: from TTN to device. We have other downlinks ???
??? Well. Technically my payload it is better since it uses less bytes for more info.
So my 7 bytes payload is bad? (again: Out-of-topic but I am watching #2)
Well, at least you are placing the blame where it’s due - this disaster indeed happens if you try to use a node firmware that doesn’t actually implement LoRaWAN, on a LoRaWAN network.
Don’t do that
Apologies, I thought you were trying to create something yourself:
So you may see why I thought you were designing your own tracker.
As for my geo payloads, if they are relatively stationary and/or only need to report where they are when stationary for a decent amount of time, then I use two integers aka 4 bytes, if it’s transmitting on the move, then I mostly send deltas and/or turns (because they are a pallet on a truck on a highway). This maximises battery life considerably. Most of my trackers are for assets, not people. I have used LoRa for tracking with a mesh and I have tried using LoRaWAN in combination with SMS & GSM/LTE but that gets complicated. Sometimes WiFi comes in to the mix which is useful for pre-movement ephemeris updates.
As for the side swipe at TTN for what you dub TinyLoRa-gate, perhaps you should ask the person who installed the firmware what they were thinking.
@descartes yes, I am trying to do something to share / help with people like the OP.
So you think that a 7 bytes payload is a problem for GPS tracking as OP wants and the 4 bytes is the solution and is more useful than my idea of white zones? (Blind ADR on steroids)
@cslorabox I don’t use it anymore. Enough with the TinyLoRa-gate.
You asked what sort of payload I used for tracking. I minimise the payload to keep the transmission time down so I can burn battery on keeping the ephemeris up to date.
I don’t think there’s a particular problem with 7 bytes, I think there is a huge problem with the design & expectations of generic tracking. So any discussions without a specific use case doesn’t move us forward.
I think my idea of Blind ADRoS (Blind ADR on Stereoids - hey you make me create a name) is beneficial to all GPS tracking devices. Do you have some idea why is not beneficial? Yes: I know it’s difficult to implement. I find it more easy than what you did (relative / optimized GPS data).
Even if you can map only 10 GW’s this will be beneficial for those 10 GW’s.
I don’t think that the LoRa(WAN) payload can save enough battery for the power hungry GPS unless you transmitting too often. It think it’s more beneficial to use lower SF / power than to save 3-4 bytes that it’s beneficial only by some SF’s.
Out of topic follows.
Re-read the topic please.
In my view, the main culprit for “viability of trackers” is not the payload but the absence of GW’s. I proposed my ideas to have “viability of trackers”. a) more GW’s b) Blind ADRoS.
I wrote about my 7bytes payload to prove that the payload is not a problem. This payload can cover heading, speed, gps qual, battery and positioning (stand / fall). Some other person asked about specifics. Still wondering why. Your payload lowers my payload to 5 bytes. Will not make the trackers more viable.
I asked specific question about FSK vs LORA in close distance to GW and never got an answer. I referred to payload because you asked for more. You even wanted conversation about my “0 bytes” payload (gps fix / gps qual / stand / battery e.t.c.)
ON topic.
I already mentioned that I can optimize with what you did with the Lat/Lon data. Glad to know that I can save 2 bytes. You verify that the my effort to save bytes will not be so rewarding than to lower the SF’s to save battery and to increase the capacity of the network. That’s the reason it’s last on my priority list.
@descartes LoRaWAN adds much to the payload, so better to lower SF / power. Right?
Still don’t know if FSK is better than LoRa close to GW.
But better to re-post about TinyLoRa-gate.
@nashenden I don’t know if I will make it. My project is open source but immature / experimental to make it known / usable. If it will be functional I will post with Blind ADRoS topic I hope in the meantime that some programmer better than me can create the implementation.
and
Erm excuse me but @LoRaTracker commented and I answered you directly 5 days ago - Note: you even ‘Liked/Hearted’ my post!!! NB The 1st generation devices (SX1272,76(& 77/78/79 band specific derivatives) all were based on the previous legacy SMTC devices the SX1232/5 etc. - basically these devices with LoRaModem/Codec added…and are therefore comparable in performance wrt FSK operation as that family. You are good down to around -110–115db on RSSI (lower depending on SNR,theoretically to <<-120, but it is the SNR that will kill you if it falls too low - also be wary of seeing a steady state or instantaeous value and assuming local environment good, as burstly RF noise may catch you out even if numbers look good on a given instance…LoRa has additional interferer (impulse and steady noise floor related) resiliance & mitigation that means that at a given data rate it will always win out
Mod hat on…
It does feel like this thread is getting a little away from topic and a touch heated so perhaps all take a step back.
We as a small group of users and near experts are unlikely to solve a problem that has taxed a great many larger brains over a longer period so if we have questions/concerns wrt trackers perhaps we look to join this Things Webinar/Conf session on Logistics and tracking/GPS enable solutions due in a few weeks and ask some of our questions and challenge assumptions here: 