Select to expand quote

FormulaNova said..
I have noticed that the red light on the GPS module is always on when its powered up. The green led lights up when it sends data, which looks to be every second. In my house, the GPS modules seem to work inside, but having a tiled roof may be the reason for that.

Your GPS module is probably different from the one I have, although mine is also a ublox 8. My module sends NMEA data right away when powered up; most of the numbers are 9s, 999 etc. if it does not have a satellite fix. The green light blinking once it has a satellite fix. IIRC correctly, the VK172 USB dongle behaves the same way.

My ublox module ((https://www.amazon.com/gp/product/B012RNLG0K/) has a 3.3 voltage regulator, so either 3.3 or 5V works fine. Again, yours may vary.

Select to expand quote

decrepit said..
And Samba has stopped working on the Pi.

Did you follow the instructions at www.ecwindfest.org/GPS/ and edit your /etc/rc.local file?

If so, the start_logger.py script will turn off the WiFi a few seconds after you plug your converter into the USB port. That will happen as soon as you see a device at /dev/ttyUSB0, even if the GPS chip is not connected to the USB-serial converter (or not connected correctly).

When you're using minicom, the start_logger.py script should probably not be running, since the logger app may block the serial port. Best thing to do is to comment out the line in /etc/rc.local, and reboot the Pi. Then use something like
ps -cax | grep start_logger
to make sure that the script is not running.

Once you see that everything works as expected in minicom and/or ucenter, and you want to use the logging software, just remove the comment, and restart. It will definitely help to start with a VK172/162 dongle, since that removes a few spots where things can go wrong.

Select to expand quote

boardsurfr said..

FormulaNova said..
I have noticed that the red light on the GPS module is always on when its powered up. The green led lights up when it sends data, which looks to be every second. In my house, the GPS modules seem to work inside, but having a tiled roof may be the reason for that.

Your GPS module is probably different from the one I have, although mine is also a ublox 8. My module sends NMEA data right away when powered up; most of the numbers are 9s, 999 etc. if it does not have a satellite fix. The green light blinking once it has a satellite fix. IIRC correctly, the VK172 USB dongle behaves the same way.

My ublox module ((https://www.amazon.com/gp/product/B012RNLG0K/) has a 3.3 voltage regulator, so either 3.3 or 5V works fine. Again, yours may vary.

Yes, you are probably correct. I have never looked at the initial output, and have only looked at the module, and the led, once it has already got a satellite fix.

I suspect the problem with running the module from 5v is the USB to serial converter may be expecting higher level serial signals than the GPS modules is sending when its is set to 5v mode.

Edit: I just checked it by powering up the converter first, and then powering up the GPS module. It sends data straight away, and as you say, initially sends all 9's. The green led does not light.

It then starts to get changing figures, but the led still doesn't light. I am guessing its not a minimum number of satellites or something not up to the minimum requirements.

Then the green led starts blinking, at which point I guess it has a satellite fix.

It only seems to behave this way when its started cold. If I power it up again after its been on recently, it seems to get a fix straight away which is probably the onboard cap retaining power to keep satellite information.

I also tried it at 5v, and my setup works fine on 5v too.

Select to expand quote

boardsurfr said..

Did you follow the instructions at www.ecwindfest.org/GPS/ and edit your /etc/rc.local file?

Yes, /etc/rc.local is modified as directed.

It's weird, seems to turn the Pi off when the converter is plugged in and turn it on when it's unplugged?
Could just be my imagination though.
But I've just done another test outside, had a green flashing light for 14hr Unplugged the converter from the pi, came inside and connected to TV, keyboard and mouse, and it was half way through the boot sequence. Maybe plugging keyboard mouse and TV in started the boot sequence, but I thought it was further into it than that. then I checked /home/pi/Documents/PiLogger. and only your original text file is there.

And I've just realised another thing, the windows were much too big for the screen, huge font had to scroll like mad, when I reboot it goes back to normal. So I'm assuming it got well into the boot process before I connected the TV, so didn't automatically set the correct resolution.

Select to expand quote

If so, the start_logger.py script will turn off the WiFi a few seconds after you plug your converter into the USB port. That will happen as soon as you see a device at /dev/ttyUSB0, even if the GPS chip is not connected to the USB-serial converter (or not connected correctly).

That makes sense, but unfortunately it's not the problem, even without the converter connected and wifi on, there's still no pi in samba.

Select to expand quote

When you're using minicom, the start_logger.py script should probably not be running, since the logger app may block the serial port. Best thing to do is to comment out the line in /etc/rc.local, and reboot the Pi. Then use something like
ps -cax | grep start_logger
to make sure that the script is not running.

That's another of my problems, as I don't have a usb hub, I only have 1 gps connection, so once the converter is plugged in, nothing else can be.
So I can't actually check up on what's happening in the pi.
I don't want to add your script to rc.local on this computer.

Select to expand quote

It will definitely help to start with a VK172/162 dongle, since that removes a few spots where things can go wrong.

I agree wholeheartedly, I have one on order, should be here next week.

I think my next trick is to fire up the laptop so I can see what I get with a fix.

I'm a bit suspicious that the raspberian kernel doesn't have the converter driver

Hmmmmm,

well minicom on the laptop with a fix, (after I remembered to set baud rate to 9600) returns a string of this stuff.

$GNVTG,,T,,M,0.884,N,1.637,K,A*3A
$GNGGA,082509.00,3235.38114,S,11538.51213,E,1,08,1.35,2.4,M,-31.2,M,,*7F
$GNGSA,A,3,07,03,16,22,23,30,,,,,,,2.03,1.35,1.52*1D
$GNGSA,A,3,78,79,,,,,,,,,,,2.03,1.35,1.52*1D
$GPGSV,3,1,09,01,00,013,,03,37,058,35,06,42,265,,07,57,329,30*72
$GPGSV,3,2,09,09,61,200,17,16,19,115,24,22,13,051,21,23,44,128,12*7B
$GPGSV,3,3,09,30,28,325,28*47
$GLGSV,3,1,10,66,08,076,19,67,47,116,23,68,42,202,,69,16,090,*6B
$GLGSV,3,2,10,77,48,133,19,78,61,029,28,79,24,354,21,82,02,325,23*6D
$GLGSV,3,3,10,83,18,279,17,84,12,224,*67
$GNGLL,3235.38114,S,11538.51213,E,082509.00,A,A*6E
$GNRMC,082510.00,A,3235.38121,S,11538.51212,E,0.598,,090518,,,A*79
$GNVTG,,T,,M,0.598,N,1.107,K,A*3E
$GNGGA,082510.00,3235.38121,S,11538.51212,E,1,08,1.35,2.5,M,-31.2,M,,*71
$GNGSA,A,3,07,03,16,22,23,30,,,,,,,2.03,1.35,1.52*1D
$GNGSA,A,3,78,79,,,,,,,,,,,2.03,1.35,1.52*1D

So does this look like data of some sort?

I then installed the converter driver and ucenter on laptop windows. I was hoping to download a ubx file to check the geostationary performance. But for some reason, didn't get a com port like I did on this computer, so couldn't get a connection.

Select to expand quote

decrepit said..
Hmmmmm,

well minicom on the laptop with a fix, (after I remembered to set baud rate to 9600) returns a string of this stuff.

$GNVTG,,T,,M,0.884,N,1.637,K,A*3A
$GNGGA,082509.00,3235.38114,S,11538.51213,E,1,08,1.35,2.4,M,-31.2,M,,*7F
$GNGSA,A,3,07,03,16,22,23,30,,,,,,,2.03,1.35,1.52*1D
$GNGSA,A,3,78,79,,,,,,,,,,,2.03,1.35,1.52*1D
$GPGSV,3,1,09,01,00,013,,03,37,058,35,06,42,265,,07,57,329,30*72
$GPGSV,3,2,09,09,61,200,17,16,19,115,24,22,13,051,21,23,44,128,12*7B
$GPGSV,3,3,09,30,28,325,28*47
$GLGSV,3,1,10,66,08,076,19,67,47,116,23,68,42,202,,69,16,090,*6B
$GLGSV,3,2,10,77,48,133,19,78,61,029,28,79,24,354,21,82,02,325,23*6D
$GLGSV,3,3,10,83,18,279,17,84,12,224,*67
$GNGLL,3235.38114,S,11538.51213,E,082509.00,A,A*6E
$GNRMC,082510.00,A,3235.38121,S,11538.51212,E,0.598,,090518,,,A*79
$GNVTG,,T,,M,0.598,N,1.107,K,A*3E
$GNGGA,082510.00,3235.38121,S,11538.51212,E,1,08,1.35,2.5,M,-31.2,M,,*71
$GNGSA,A,3,07,03,16,22,23,30,,,,,,,2.03,1.35,1.52*1D
$GNGSA,A,3,78,79,,,,,,,,,,,2.03,1.35,1.52*1D

So does this look like data of some sort?

I then installed the converter driver and ucenter on laptop windows. I was hoping to download a ubx file to check the geostationary performance. But for some reason, didn't get a com port like I did on this computer, so couldn't get a connection.

Yeah, that's NMEA data.

You haven't read the spec???

I looked at it just to figure out if I was getting NMEA or Ublox format. That is NMEA, although you can have vendor specific NMEA codes, with Ublox codes possible.

Why couldn't you get a com port on the laptop? Does it require special drivers for the USB to serial converter? I was hoping that they were that common that windows had drivers built in.

Device Manager should help as the USB adapter will probably show up under 'com and Lpt ports' as a USB serial adapter.

The UBX format is binary, so it may not be as easy to capture it, but then again, if you can figure out how to capture a binary file, it won't be that complex.

Are you comfortable using u-center to change the GPS settings, or does the scripting do that for you?

Select to expand quote

FormulaNova said..
Yeah, that's NMEA data.

Fantastic, something's happening

Select to expand quote

You haven't read the spec???

reading specs is an action of last resort, that only happens when things don't work.

Select to expand quote

Why couldn't you get a com port on the laptop? Does it require special drivers for the USB to serial converter? I was hoping that they were that common that windows had drivers built in.

Took me by surprise as well, it was only when I read the specs, I found the instruction to install the driver. Both my Ubuntu installations in PC and laptop have the driver in the kernal. Both my windows 7 installs haven't.

Select to expand quote

Device Manager should help as the USB adapter will probably show up under 'com and Lpt ports' as a USB serial adapter.

thanks I'll have a look

Select to expand quote

Are you comfortable using u-center to change the GPS settings, or does the scripting do that for you?

I've no idea about it, but playing with it yesterday I thought I saw a button that said save ubx data?

I haven't yet worked out how to even see the config settings let alone edit it. I'm even wondering if the ublox chip can receive instructions.

I'll have another play with it on here, and maybe even read the manual

I've had another play, and read the manual, (well skimmed would be more accurate).
Pressing the record button saves a .ubx file, but having no fix, there's nothing on it

It indicates I'm connected to the converter, but it doesn't look as if it's connected to the gps module, even though minicom is, because I get this when I hit the record button.
Polling: MON-VER - B5 62 0A 04 00 00 0E 34 ...
... timeout occurred without receiving an answer. Retrying...!
Polling: MON-VER - B5 62 0A 04 00 00 0E 34 ...
... failed due to timeout!
Polling: CFG-ANT - B5 62 06 13 00 00 19 51 ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-ANT - B5 62 06 13 00 00 19 51 ...
... failed due to timeout!
Polling: CFG-DAT - B5 62 06 06 00 00 0C 2A ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-DAT - B5 62 06 06 00 00 0C 2A ...
... failed due to timeout!
Polling: CFG-DGNSS - B5 62 06 70 00 00 76 68 ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-DGNSS - B5 62 06 70 00 00 76 68 ...
... failed due to timeout!
Polling: CFG-DOSC - B5 62 06 61 00 00 67 3B ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-DOSC - B5 62 06 61 00 00 67 3B ...
... failed due to timeout!
Polling: CFG-EKF - B5 62 06 12 00 00 18 4E ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-EKF - B5 62 06 12 00 00 18 4E ...
... failed due to timeout!
Polling: CFG-ESFGWT - B5 62 06 29 00 00 2F 93 ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-ESFGWT - B5 62 06 29 00 00 2F 93 ...
... failed due to timeout!
Polling: CFG-ESRC - B5 62 06 60 00 00 66 38 ...
... timeout occurred without receiving an answer. Retrying...!
Polling: CFG-ESRC - B5 62 06 60 00 00 66 38 ...
... failed due to timeout!

Select to expand quote

decrepit said..

Yes, /etc/rc.local is modified as directed.

Since you get NMEA data on Windows, you know that your cables are correct, and that the serial converter works. You do not need to install any drivers for it on the Pi.

The next thing is to verify that you can get the same data on the Pi with minicom. Below are a few things you can do. Step 1 is essential.

1. Undo the modification in /etc/rc.local ,or comment the line in /etc/rc.local out,or(better yet) comment the entire block labeled
#turn HDMI and WiFi off to reduce energy consumption, ignoring any errors
out (add a # at the start of each line).

2. Get a USB hub. Just about any hub would work. But it's quite possible that a mouse would mount at /dev/ttyUSB0/, so plug in the GPS first. If you did not do step 1, that will turn of WiFi and the TV signal.

3. Plug the TV in before you boot. If the resolution remains too low, Google how to change it. There's a "Settings" or "Preferences" menu, but that won't work if the resolution is really low (the window it opens is too large). There's also the command line to open raspi-config, which should work even with low resolution.

4. The easiest way to control the Pi is by screen sharing through VNC. The current Raspbian version has a VNC server installed, but you need to change the authentication. Also, issues 1. and 3. apply.

5. Look at the scripts to see what they do. They should be easy enough to understand. For example, you'd see that the start_logger script turns WiFi off before starting to log (to increase battery life), and turns it back on when the logging is done (when the dongle is disconnected). It also calls the "logging_done" script, which shuts down the Pi after a 2 minute delay.

Select to expand quote

decrepit said..
I've had another play, and read the manual, (well skimmed would be more accurate).
Pressing the record button saves a .ubx file, but having no fix, there's nothing on it

The ubx file is empty because something's wrong with the connection to the GPS. Even without a fix, the ubx file usually contains some info.

Using minicom and ucenter is an either-or thing, you can't use both at the same time. Serial ports are generally locked by programs that use it, and not available for other programs. So minicom blocks it. Quit minicom and ucenter, close the terminal program, disconnect the USB converter. Then start ucenter, connect the USB converter, open the port in ucenter, and check the packages window or the text window. ucenter has lots of windows to look at the data coming across, there's usually no need to record to a file.

Sorry I'm not being clear here. when changing from minicom to ucenter I'm changing operating systems first.
I use ubuntu mate for minicom and windows 7 for ucenter.

And the converter definitely needs a driver, it's manual says so, with instructions how to install it, and once I'd done that I started to get some results with windows. Ubuntu has the driver in the kernal so that's not a problem.

raspberian on pi runs on a different platform to ubuntu on a PC. I doubt the ubuntu driver will work in raspberian, but that may not be the problem.
I think things will become clearer when the dongle arrives, but yes getting a usb hub is probably the next step.

Select to expand quote

decrepit said..
Sorry I'm not being clear here. when changing from minicom to ucenter I'm changing operating systems first.

On the same computer or a different computer? Does this involve rebooting, or are you running ubuntu as a virtual machine? If it's a virtual machine, the blocking can still apply. If you're rebooting or using a different PC, it could be a driver issue on Windows. Theoretically, it could be the wrong baud rate, but I think that ucenter usually automatically detects the baud rate.

Select to expand quote

decrepit said..
raspberian on pi runs on a different platform to ubuntu on a PC. I doubt the ubuntu driver will work in raspberian, but that may not be the problem.
I think things will become clearer when the dongle arrives, but yes getting a usb hub is probably the next step.

Raspbian is very close to ubuntu. The kernel has the drivers for the most common USB-to-serial converters. I did not have to install drivers on Raspbian to get the two dongles (VK172 and 162) and a USB-to-serial converter to work. However, there are a few different chips used in different converters, so it's theoretically possible that you'd need to install a driver. But it's quite unlikely.

You should be able to use the logging program directly on your ubuntu PC, though. It's plain Java, which is probably installed already (or should be easy to get if not). You'd need to install the RXTX library, though (check rxtx.qbang.org/wiki/index.php/Main_Page), and adjust the locations for cp and library.path in the launch command.

Thanks Pete.
A bit of both, I have a PC and a laptop, both have windows 7 and ubuntu 16.04 separate installations

Initially I was using the PC in here booting between windows and ubuntu. But because of a lack of fix indoors, I used the laptop outside.

Both have identical minicom in ubuntu and ucenter in windows with downloaded converter driver.
Minicom works in both, but only the PC can connect to the converter in windows.

So obviously it would be good to try installing the RXTx libraries in the laptop ubuntu, and see if it will record data. I looked very much like binary to me when I had a fix.

I've now got a usb hub, so I'll have another play with the pi as well

Select to expand quote

decrepit said..
So obviously it would be good to try installing the RXTx libraries in the laptop ubuntu, and see if it will record data. I looked very much like binary to me when I had a fix.

The package window in ucenter tells you what kind of messages you receive. The default for ublox chips is NMEA. But that can sometimes look like binary in minicom if the baud rate is wrong. If you get ucenter to work with the converter + GPS on your PC, you can check the menus to see what the correct baud rate is, assuming "autobauding" is on.

Select to expand quote

decrepit said..
Both have identical minicom in ubuntu and ucenter in windows with downloaded converter driver.
Minicom works in both, but only the PC can connect to the converter in windows.

Sounds like the driver is not working in your laptop. Try installing again, with reboots before and after. If you know the chip in the converter (FTDI, Prolific, ...), you may also be able to find a different driver for it.

It's a Silicone Labs CP210. I've just found another link telling how to install it with the converter hooked up. I installed it before conecting the converter, so maybe windows doesn't pair them up? So if I get time in the next day or so I'll have another go at the laptop

I've been playing around with e-paper displays a bit. The 2.13 in HAT versions from Waveshare fit the Zero WH quite nicely. But the "fancy" 2-color version (red, white, and black) is useless, though, since it supports only full updates, which take 15 seconds (!), with lots of screen flicker.

The regular back and white version is more promising, with partial updates in the 1-2 Hz range possible. However, Python may not be a good choice here: just running a simple demo program that shows the time in smallish font keeps the CPU busy at around 30%. Running the C demo programs use less than 10% CPU. 30% would likely be a problem since the Zero is a single-core computer, and might end up missing GPS data. I was a bit surprised to see the large performance differences, but maybe I should not have been, since Python does not have a JIT compiler like Java.

Pete you were correct Raspbian has the converter drivers in it's kernel.
The USB hub works a treat, so I had everything working with a fix.
Strangely Minicom had vanished, I had to reinstall it. But once that was working I could see NMEA data coming in. but nothing happening in "PiLogger". So I checked your python script and noticed it was looking for " dongle = Path("/dev/ttyACM0")" So I changed to minicom to look for "/dev/ttyACMO" and I got an error message back saying device doesn't exist. So I edited the script, (saving a backup) to USB0 restarted the pi with device plugged in, TV went blank, bit of a worry, no indicators that the Pi is working, except the lights on the converter and GPS module are still on.

So then unplugged the converter, and re-powered the Pi. Zippy Dooo, there's now a .ubx file in PiLogger.

Now I just have to get it into this computer. Thinking if minicom can disappear so can bits of samba, ended up doing a samba purge and reinstall, but I get an error message from the NMB daemon saying it failed to start.

I've installed "vino" on this computer but I can't figure out how to work it yet. There's no sign it's even here, no gui and calling it from the terminal does nothing either, no man files nothing. So I'm back to the mate forum and google.

So I've just checked the Pi, that's using "realvnc", so I tried that here on mate and it's not in the repos.

Cheated and went the long way round, mailed it to myself.
But big disappointment, GPSResults says it can't read binary file, no trackpoints there.
So baud rate problem maybe???

Select to expand quote

decrepit said..
Pete you were correct Raspbian has the converter drivers in it's kernel.
The USB hub works a treat, so I had everything working with a fix.
Strangely Minicom had vanished, I had to reinstall it. But once that was working I could see NMEA data coming in. but nothing happening in "PiLogger". So I checked your python script and noticed it was looking for " dongle = Path("/dev/ttyACM0")" So I changed to minicom to look for "/dev/ttyACMO" and I got an error message back saying device doesn't exist. So I edited the script, (saving a backup) to USB0 restarted the pi with device plugged in, TV went blank, bit of a worry, no indicators that the Pi is working, except the lights on the converter and GPS module are still on.

So then unplugged the converter, and re-powered the Pi. Zippy Dooo, there's now a .ubx file in PiLogger.

Now I just have to get it into this computer. Thinking if minicom can disappear so can bits of samba, ended up doing a samba purge and reinstall, but I get an error message from the NMB daemon saying it failed to start.

I've installed "vino" on this computer but I can't figure out how to work it yet. There's no sign it's even here, no gui and calling it from the terminal does nothing either, no man files nothing. So I'm back to the mate forum and google.

So I've just checked the Pi, that's using "realvnc", so I tried that here on mate and it's not in the repos.

Glad you got to see NMEA data on the Pi, and figured out how to change the script for your converter.

It's theoretically possible that the unreadable .ubx file is due to baud rate issues, although I think it's unlikely. My guess is that the file got damaged when you "transferred" it by email. For example, if one of the programs involved treated it as a text file, that would damage it. I've seen this happen before. If you have not already done so, try compressing the file first, and emailing the compressed file. Gzip or Zip should work.

As for the TV going blank, check the script you edited. There are two lines that turn off the WiFi and the HDMI output to reduce battery use. Just comment them out, battery use is irrelevant right now.

Also, once you disconnected the dongle, wait 3 minutes - the Pi should shut down after 2 minutes (if you commented out the two lines as suggested, you should be able to see the shutdown on the TV screen). If you get SAMBA working again, then you should be able to copy the .ubx file in these two minutes .

Select to expand quote

boardsurfr said..
I've been playing around with e-paper displays a bit. The 2.13 in HAT versions from Waveshare fit the Zero WH quite nicely. But the "fancy" 2-color version (red, white, and black) is useless, though, since it supports only full updates, which take 15 seconds (!), with lots of screen flicker.

The regular back and white version is more promising, with partial updates in the 1-2 Hz range possible. However, Python may not be a good choice here: just running a simple demo program that shows the time in smallish font keeps the CPU busy at around 30%. Running the C demo programs use less than 10% CPU. 30% would likely be a problem since the Zero is a single-core computer, and might end up missing GPS data. I was a bit surprised to see the large performance differences, but maybe I should not have been, since Python does not have a JIT compiler like Java.

Thanks for the update.

As I'm looking at making a PCB hat for the pi, I have ordered a 1.3" oled (white on black) running on I2C to evaluate in terms of performance and use in sunlight conditions.

I finally have a Pi zero W now, so my journey has at least started, but still waiting on other parts (including GPS) so I can tinker further.

Select to expand quote

boardsurfr said..
My guess is that the file got damaged when you "transferred" it by email. For example, if one of the programs involved treated it as a text file, that would damage it. I've seen this happen before. If you have not already done so, try compressing the file first, and emailing the compressed file. Gzip or Zip should work.

As for the TV going blank, check the script you edited. There are two lines that turn off the WiFi and the HDMI output to reduce battery use. Just comment them out, battery use is irrelevant right now.

Also, once you disconnected the dongle, wait 3 minutes - the Pi should shut down after 2 minutes (if you commented out the two lines as suggested, you should be able to see the shutdown on the TV screen). If you get SAMBA working again, then you should be able to copy the .ubx file in these two minutes .

Thanks Pete, I hadn't considered that emailing could corrupt, I'll give Gzip a go.
I've had some good help from the Pi forum, but haven't got around to trying the latest advice.

My next question was going to be, is it safe to comment out the WIFI HDMI off script.

Should have further developments tomorrow.

And great work with the display, but I'll be a while before I get there.

Select to expand quote

srtgumbee said..
>>>>, but still waiting on other parts (including GPS) so I can tinker further.

What happened to the one you pulled the chip off?

A bit of a surprise yesterday: I got some first data with my u-blox 8 + Bluetooth + Android from a test drive, and the data did look quite bad. SDoP much higher, fewer sats, obvious "bad areas" in the speed over multiple seconds. It does seem to be a genuine ublox, I was able to upgrade the firmware to 3.0.1 (and it cost $30), although that's not definitive.

Thinking it might be the bluetooth, I hooked it up over USB and compared it to a ublox7 with a same-sized (25 mm) antenna. The older chip got more satellites, and had lower SDoPs. Strange. Maybe it's a fake ublox chip, after all. The company lists "Weak sensitivity and overall performance" as one of the possible problems with Chinese rip-offs.

Well, I just verified that my "ublox 8" is a poorly functioning ripoff. The telltale was that it shows only 32 available channels in ucenter; the original chip has 72 (according to www.rcgroups.com/forums/showthread.php?2693310-M8N-GPS-list-of-fake-good-and-original).

One reason I though this was an original was that one of the reviews on Amazon said so. But that either was a paid-for review, or whoever wrote it had no clue, or the seller used different chips for different batches. The one I bought is here: https://www.amazon.com/gp/product/B012RNLG0K/.

Since most of the ublox 8 chips on the market (including most or all that are directly shipped from China) are ripoffs, and their performance and upgradability varies, it's a good idea to do a side-by-side comparison to a ublox 7 device.

Hmmm, now you've got me thinking.

It's not going to be a simple process to approve DIY devices as a group, if some could have bad chips.
It's going to have to be an individual thing.
I hope mine's OK.

Select to expand quote

decrepit said..
It's not going to be a simple process to approve DIY devices as a group, if some could have bad chips.
It's going to have to be an individual thing.

Yes, you are right. If it's DIY, it needs some kind of validation protocol. That's a bit of an argument for a "plug & play" approach with dongles .. although it's a different question if all VK172s (etc.) indeed use the same chip, so a bit of validation would be needed for those, too.

Here's a screen shot that shows one bad area from the test drive (GW-60 in blue/left side of table, ublox8 ripoff in red):


The error in the "ublox 8" data is 1-2 knots over more than 2 seconds (5 Hz data). This is not the worst area in the track either (where the difference was closer to 10 knots, possibly under a bridge or so). These are just about the worst data I have seen in all of my tests.

I have just updated the firmware in my module to at least check that that was possible and it worked.

I used the instructions at www.rei-labs.net/how-to-update-neo-m8n-firmware/

I guess that doesn't mean its not a knock-off though, as it could just be a better knock-off with flash instead of rom.

Just tried zipping and re-emailing, no luck, file still unreadable.

I've just commented out the wifi and monitor shutdown.
watching the file in pilogger it starts as expected, but stops as soon as the GPS starts seeing satellites, just a bit before it gets a fix.

Can I manually start the logger, after the fix?

Now I can see the Pi shutdown after gps disconnection, but it did take longer than I expected. I'll have to remember that when there's no monitor.

Select to expand quote

decrepit said..
Just tried zipping and re-emailing, no luck, file still unreadable.

I've just commented out the wifi and monitor shutdown.
watching the file in pilogger it starts as expected, but stops as soon as the GPS starts seeing satellites, just a bit before it gets a fix.

Can I manually start the logger, after the fix?

Now I can see the Pi shutdown after gps disconnection, but it did take longer than I expected. I'll have to remember that when there's no monitor.

Do you know what baud rate the scripting expects? Are there any entries in there that look like a baudrate, i.e. 9600, 38400, or 115200?

Its possible that the USB dongle speed is set differently, and you might need to initially set the baud rate of the GPS module. I would suggest 115200 as its the fastest most common baudrate. You can set that in u-centre by going to the configuration view, and then selecting ports. By default it will have 9600 there, you just change it to 115200 and then hit the 'send' button/icon. It should stop responding as it is now at the wrong baudrate, until you go back into the Receiver/Baudrate menu and then set that to 115200 also.

Pete's software is meant to set the baud rate to 9600, which seems to work with minicom.
I haven't got u-center to work yet. windows and I just don't get on.

Select to expand quote

decrepit said..
Pete's software is meant to set the baud rate to 9600, which seems to work with minicom.
I haven't got u-center to work yet. windows and I just don't get on.

Really? 9600 is fine for 1hz updates but it won't be anywhere near fast enough for 10hz UBX updates. I wouldn't be surprised if it uses a higher baudrate as 9600 won't be enough.

You can't get u-center to work? Its a piece of cake. As long as you have your serial driver working, it will work fine.