Gateway beacon coordinates (Class B)

the gateway has gps installed and working (from the web dashboard)

RAK7285C
MODEL

37.422134, -121.956215
REPORTED COORDINATES

which is correct for san jose, ca, usa.

however, when i join and switch to class b the coordinates in the reported beaconing doesn’t seem right.

_=u.write(‘at+ver=?\r\n’) ; _=p.poll(-1) ; u.read()
b’AT+VER=RUI_4.0.6_RAK3172-E\r\nOK\r\n’
_=u.write(‘at+class=?\r\n’) ; _=p.poll(-1) ; u.read()
b’AT+CLASS=B:S0\r\nOK\r\n’
_=u.write(‘at+send=7:0123\r\n’) ; _=p.poll(-1) ; u.read()
b’OK\r\n’
time.sleep(100) ; _=p.poll(-1) ; u.read()
b’+EVT:TX_DONE\r\n+BC:LOCKED\r\n+EVT:SEND_CONFIRMED_OK\r\n+BC:DONE\r\n+EVT:SEND_CONFIRMED_OK\r\n’
_=u.write(‘at+class=?\r\n’) ; _=p.poll(-1) ; u.read()
b’AT+CLASS=B\r\nOK\r\n’
_=u.write(‘at+bgw=?\r\n’) ; _=p.poll(-1) ; u.read()
b’AT+BGW=0:0:0:3488352:11095835\r\nOK\r\n’

that is somewhere in china? not sure if this is a device or gateway or something else issue?

1 Like

Good morning,

A GNSS system need some time to create a Almanac ( a list of all satellites in the your sky region). For example, the RAK12500 (u-blox), can require until 12 minutes to complete the Almanac information. Other important point is the sky portion without obstacles. For example, if your gateway is installed in a building wall, all space behind the build is blocked and this kind of situation reduce the location precision. But it can be fixed moving the gatewa instalation to the roof :slight_smile:

Regards,

Cláudio

hmmm… the gateway is on the roof of thebuilding and has been up for ~30days, it might have gotten reset (by accident recently).

How did you mount GPS antenna? Is this way?

Here is the 7285 documentation

visually, the gps is installed correctly. the gateway logs show it doing pps sync w/ gps. also the main status page shows ‘close’ enough coordinates (in my first post) i’m wondering why the beacon info at the device doesn’t reflect the coordinates on the gateway status page.

Tue Aug 27 21:05:03 2024 user.info basicstation[6364]: [SYN:INFO] MCU/SX130X drift stats: min: -1.1ppm q50: +10.3ppm q80: +18.9ppm max: -27.6ppm - threshold q90: -23.4ppm

the device is running the last rak fw and i’m not sure that there’s better visibility into the beacon other than the at-command events.

Here is the install photo.

My comment don´t have a relation with GNSS problem, but this Does installation has protection for lightning?

The antenna couldn´t be the highest thing in your installation because if you have a lightning storm, the gateway/antenna will blow out.

Pay attention in the instalation figure that I sent with the protection recommendations.

Claudio

Because this is a demo build we don’t have one b/w the antenna and gateway but we do have one on the POE. Other lightning arrestors in the vicinity are mounted higher than the gateway.

Hi @utg @peter.chang ,

I am checking now this issue with our RUI3 team. I will get to you ASAP once I got any update.

PS We can also continue our communication via email if you prefer that support comms. Also, I moved the category to RAK3172 since it seems to be a device issue and not gateway.

Also, I moved the category to RAK3172 since it seems to be a device issue and not gateway.

thanks. i wasn’t sure where this was coming from.

Hi @peter.chang @utg ,

May I know the LNS you use? Are you using the built-in network server of WisGate?

May I know the LNS you use?

we’re currently attaching to whatever aws uses going through the basicstation on the gateway. afaict (via the aws packet capture thing on their lora setup) there aren’t any proprietary frames on the LNS, just the join/data.

[ edit for the sign bit ]

so i realize that these are the ‘raw’ values not degrees or dms units.

3488352 / (1 << 23) * 90 == 37.426
-5706723 / (1 << 23) * 180 == -122.452988

whch is close?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.