Use time and PPS from GPS but fake coordinates in poly_pkt_fwd

(Bjoern A) #1


is it possible to use time and PPS from GPS but fake coordinates with the poly_pkt_fwd?

I am playing arround with an Ublox GPS module. Al is working fine, except that i don’t have a steady position. My coordinates wander about 100m. Root cause is that the active antenna is positioned behind a window and it is not possible for me placing it at a better position. The module is configured in static mode with SBAS enabled but without any success.
The bad side affect is, that all past mapping data on ttnmapper gets lost.

Thanks in advance.

(Gijs Mos) #3

Checked the code in the poly_pkt_forwarder version I run on my RAK831/MAX-7Q (from //

Cheking the poly_pkt_forwarder code i find:

    if (gps_enabled == true) {
            if (gps_fake_enable == false) {
                    i = lgw_gps_enable(gps_tty_path, NULL, 0, &gps_tty_fd);
                    if (i != LGW_GPS_SUCCESS) {
                            printf("WARNING: [main] impossible to open %s for GPS sync (check permissions)\n", gps_tty_path);
                            gps_active = false;
                            gps_ref_valid = false;
                    } else {
                            printf("INFO: [main] TTY port %s open for GPS synchronization\n", gps_tty_path);
                            gps_active = true;
                            gps_ref_valid = false;
            } else {
                    gps_active = false;
                    gps_ref_valid = false;

So, as soon as you use the fake_gps option, reading out the GPS is not even started.

Browsing the code a bit, it appears that altering the semantics of the “fake_gps” option a bit would not be difficult. Now it means: ignore the “gps” option, don’t use the gps and use the coordinates from the config file. In a new meaning it could leave the gps use switched by the “gps” option, and then replace the lat/lng/alt by the configured fixed values. What you want.
Probably better not to use “fake_gps” for that since it might create a lot of confusion. A new option “use_configured_gw_location” or so might do the trick.

I have the same problem as you have. Want to use the GPS as time source to experiment witb beaconing on the RAK. So I’m considering to implement such modification.

@kersing, @johan. Agree with the analysis? Your opinion please.

(Jac Kersing) #4

First question, why beaconing? What back-end and node do you use that support class B?

Your analysis looks right. However keep in mind TTN does not want fake coordinates to be used. Why not use the real coordinates? If your gps position is not stable, do you trust the time to have the required precision?

(Gijs Mos) #5

Thanks Jac.

Beakoning just to experiment. Gateway supports it in HW and SW. And eagerly waiting for V3 which should support it if I’m right.

Then the accuracy. GPS fix is on 10-12 satellites. Wanders around a couple of meters. But with Google maps I can put the lat/lng spot on the antenna; no (hardly) error margin.
But if it TTN wants the measured value with a slight error, no problem.

(Jac Kersing) #6

It is hard to experiment when there is no support in the back-end and in nodes. :wink:

EDIT: Keep in mind beacon packets will ‘eat’ into the time on air allowance of a gateway. Gateways in EU868 have the same restrictions nodes have so only limited transmission time. And while sending a (beacon) packet the gateway is not listening for incoming data so it has other implications (less scalable network for instance) as well.

(Gijs Mos) #7

Basics might be there on the device side. LMIC library supports beacon scanning. Initiate with “void startScan (void)”. Scan ends with either a EV_SCAN_TIMEOUT or EV_SCAN_BEACON thrown. Maybe IBM knows if it really works :wink:.

Then the airtime. Valid arguments. But then, my gateway is up now for a couple of days. Sadly all TTN packets seen so far were my own. I do get more stuff, but that is all intended for the KPN network. They currently die in the TTN backend anyway. So I’m not too concerned for the beacon transmit overhead for some small scale experiments in the foreseeable future.

Then the backend. Found this on the forum for TTN V3:

Here’s a sneak peak into the topics that are going to be covered:

  1. Supporting LoRaWAN 1.1 and 1.0.2
  2. Class B, Class C
  3. Stack V3 Architecture