×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Why you should use a GPS dongle.

  • Posts: 389
  • Thank you received: 15
Hello,

I have a U-BLOX 7 USB GPS. When I was having rule problems, I also had rights problems. I could not save my position. Come to find out, VNC was not showing the child authentication wind to authenticate as Root. While this was going on, I added an RTC to my RPI4B. Did it resolve everything? No. Once I got the rules straightened out, the U-BLOX sets the time, time zone, elevation, and location. I am on Astroberry 2.03.
3 years 4 months ago #62411
The topic has been locked.
  • Posts: 1309
  • Thank you received: 226

Does your 3D Printer have a Marlin mainboard, such as in an Ender series? If so, ensure the firmware file has a unique name to any firmwares previously loaded. A Timestamp filename system is the best way to avoid the issue.
3 years 4 months ago #62422
The topic has been locked.
  • Posts: 33
  • Thank you received: 15
Pretty good guess! It's an Ender 3 V2. I've fixed it now, and it's currently printing a test faceplate for my CGEM, with 2 RJ45 ports, and a small hooded opening for a BME280 weather sensor to control dew heaters, refraction, and so forth. The actual problem I had, occurred when I tried to add a BL Touch to it , The docs showed lovely pictures and diagrams to be sure you plugged it in the right way, except that I have the newest 4.2.7 mainboard, which is wired differently. When I plugged in the BL Touch, it let the smoke out of my mainboard. New mainboard, different software, and hours of bed leveling, offset calculation, etc - it's printing again!
3 years 4 months ago #62430
The topic has been locked.
  • Posts: 1309
  • Thank you received: 226
Ha! Thought so. I also got my first 3D printer recently.. An Ender 3 V2... And I love it! But I had issues loading new firmware from their website. It wouldn't boot. After some searching I found changing the file name did the trick.
But... I didn't have your issue releasing the ozone 'n blue smoke.. Ouch.
3 years 4 months ago #62460
The topic has been locked.
  • Posts: 33
  • Thank you received: 15
Changing the board wasn't too bad, but it was a 3-hour struggle to get BLTouch working correctly. I love it now that it's working, but not so much when I was installing it. I also added an Octoprint Pi to the printer with a 3.5" touchscreen, which lets me control the printer from remote, and includes a Pi camera to watch the print from remote also - so I don't have to stay near it to babysit it. Octoprint was a must-do upgrade IMHO, and I have several extra Pi3b's laying around.

Have you tried the Smith3D firmware? Good stuff, especially with a BLTouch.
Last edit: 3 years 4 months ago by Brian Davis.
3 years 4 months ago #62461
The topic has been locked.
  • Posts: 1309
  • Thank you received: 226
I haven't really done anything to the printer. It prints great once I tuned my Cura profiles.
3 years 4 months ago #62497
The topic has been locked.
  • Posts: 33
  • Thank you received: 15
Man, I love the Smith3D firmware. It has an AUX leveling tool in it that just takes most of the grief out of leveling the bed, and it also has tools for BLTouch that make finding the z offset easy as well. I use 5x5 bed leveling now before every print job, and haven't had a level issue since.

The BLTouch is a worth-the-hassle upgrade, but don't trust the docs.

Also, Ender did a fast shuffle with mainboards. The current board is 4.2.7 but many of the first V2's shipped with a 4.2.2 mainboard, that no one compiles firmware for.
3 years 4 months ago #62625
The topic has been locked.
  • Posts: 33
  • Thank you received: 15

A GPS is never necessary for the operation of Stellarmate. You can set your time and position by hand more accurately than you can with a dongle GPS.

Here's what a GPS really looks like (taken from a stratum 1 timeserver):


Notice that GPS reports a course and speed. Recall that this server hasn't moved so much as a millimeter in a month. The receiver averages the time variation to create a "cooked TPV" , however it has to have a PPS tied to it to get the start of second. So the time is going to be off >= a half second on each time pushed to GPSD. The location can't be averaged however, since the course and heading values are used for navigation, and need to be real time. Software using the location data should use a regression to average the value into a true course approximation, or just average the values over a period of time to get the true location (which will not be precise, but within the 10m radius error bubble of the receiver.

NTP can fix the time issue by using the PPS signal. Here's what they look like:



Here you can see the time derived from the PPS + GPS listed as ".PPS."

The GPS alone, is listed as ".GPS." (The GPS entries lower down are actually the PPS or SHM clocks at other sites)

Notice the huge offset on the GPS time, along with a massive jitter value. This means, that the time received differs from the correct time by 631ms (.631 seconds) and the reported time varies by 51 milliseconds around that offset on every (once per second) transmit from the GPS. That's a lot of error. Notice that the PPS condition time barely varies at all - .001ms or 1 microsecond. The actual value is a bit less than that.

It is a fact, that using a dongle is less accurate than using google earth to set your location/time by hand. Sorry you wasted your money.
Last edit: 3 years 4 months ago by Brian Davis.
3 years 4 months ago #62631
Attachments:
The topic has been locked.
  • Posts: 389
  • Thank you received: 15
Hello,

Under KSTARS and INDI, GPSD is PPS based under Ubuntu. With Raspbian, CHRONY provides time. I would suggest using GPSD and properly configure it. I never thought to use GPS for time. PPS was it.

If a fixed pier is an astronomer’s site, yes, a GPS dongle is wasted money. My site is variable. A GPS dongle solved one problem, taming KSTARS. Stellarium can use INDI to talk with an astronomer’s equipment. Stellarium can use all equipment in INDI. Best $7 I spent to fix my position during my variable session.

U-Blox 7 device provides PPS. PPS is part of their setup requirements. Besides, my KSTARS GPS sampling rate is 15 minutes. Within KSTARS, I can update as needed manually. As long as I know where I am, a GPS dongle, (properly configured), is a welcomed addition.

A more stable site is required for a non GPS use. Preconfigured can be setup. Besides, this is my first thread I have read which said strange things about GPS dongles. I configured mine to meet recommended settings. It worked fine. When I looked at CGPS output, I saw 9 or more satellites it was polling from. If a clear line of site, time is pretty stable under PPS.

Not everyone needs a GPS dongle. Setting up a fixed position is one step. Resetting the RPI4B clock requires logging in and setting it manually within a terminal window. All of these steps work great for a remote and fixed site with internet. Internet NTP is pretty stable. GPS dongle is not needed.

No power, no internet, and a variable location is the realm of GPS dongles. Proper setup of GPS dongle use is required. Follow the manufacturer’s recommendations.
Last edit: 3 years 4 months ago by John Robison.
3 years 4 months ago #62660
The topic has been locked.
  • Posts: 33
  • Thank you received: 15

PPS is a logic-level electrical 1hz signal. Unless you see a separate wire from your dongle attached to one of the GPIO pins on the Raspberry Pi, then no, you don't have PPS active, and no, GPSD isn't using what it doesn't have.

To enable PPS in GPSD, you must first create a /dev/ppsXX device. That is normally done by using a dtoverlay, which requires the explicit naming of the GPIO pin the PPS signal is received on. Don't know whether GPSD can be started with a missing device named in its config file or not.


Well, here's the manual and spec sheet for the U-Blox receiver, as published by the manufacturer: UBLOX-7 Manual

You'll note, that the receiver can provide a PPS pin, but only if it's packaged that way. USB is not one of the ways. Nor is PPS any part of it's "setup". INDI can't use what it doesn't have either, and so INDI is only using the NMEA time string, as processed by GPSD. I'd have to look at the default config file Jasem included, but he's pretty up on the subject, so I'm assuming he's all set up to deal with hotplug GPS dongles, and assumes anyone knowledgable enough to hook up a PPS circuit, can handle the config himself.
Last edit: 3 years 4 months ago by Brian Davis.
3 years 4 months ago #62671
The topic has been locked.
  • Posts: 1067
  • Thank you received: 140
I really don’t see what all the hype is about in this thread, a GPS is a great add on for my kit, and it gives all the needed info to the system, it is not, as has been said a bad thing at all and works very well. It only sets the time and position once during the initial set up of ekos during a session, the default setting is to not refresh...now if you were to start refreshing all the item then yes, that would not be good, but this just isn’t the case...so my GPS UBLOX dongle will stay put..... :)
Last edit: 3 years 4 months ago by AstroNerd.
3 years 4 months ago #62687
The topic has been locked.
  • Posts: 389
  • Thank you received: 15
Hello,

Yes, I did have to configure a /dev/PPS device. The RPI OS setups what is provided by the vendor.

Yes, I did consult this PDF before purchasing and using. I read this statement.

Future u-blox receivers are likely to employ multiple GNSS system times and/or receiver local times (in order to support multiple GNSS systems in parallel), so users should not rely on UBX messages
that report GNSS system time or receiver local time being supported in future. It is therefore recommended to give preference to those messages that report UTC time.


Also, USB dongle and GPIO dongles are two different things. Sufficient to say, the USB version is not producing this error. And given the GPIO pin out identified, this is still a local configuration issue and not a universal alert. As this statement attests, I can confidently use UTC time. Wow! KSTARS uses UTC also. That makes it a win for me.

Here is another.


6.6 Real Time Clock
u-blox receivers contain circuitry to support a real time clock, which (if correctly fitted and powered) keeps time while the receiver is otherwise powered off. When the receiver powers up, it attempts to use the real time clock to initialise receiver local time and in most cases this leads to appreciably faster first fixes.

I added an RTC to assist with faster locks. Also, a state of Static is when the movement Delta is near 0. Then drift is less likely when Static. With limited GPIO pins, USB is the better option. Two options exist for 3V RTC devices. Most exhaust fans block pin 1. I used the second 3V pin group. This allowed use of the RTC.
3 years 4 months ago #62689
The topic has been locked.
Time to create page: 0.513 seconds