Select to expand quote

boardsurfr said..
. So the best positioning of the GPS will need some more research.

Peter, reading the link formula posted, I found this.


Mathew also used a ground plane on his version. I think this is worth experimenting with, it may give a significant improvement.

Select to expand quote

FormulaNova said..

decrepit said..
well here it is.



Looks like a 3.3v battery to me and thanks formula for spotting this, soldered in the wrong way around, which looks to have shorted it out.

The multi meter also says it's not wired the same as the schematic shows. The big pad closest to the chip is ground, but the connection closest to the mounting hole doesn't go directly to pin 22, there's a 1k resistor in between, so the battery is on the other side of the resistor

So the question is now, can I find another battery?
More later.
My google search found a rechargeable button battery, hadn't thought of that but it makes good sense. Probably doesn't do much harm to short out a rechargeable, so I've soldered it back in the correct way round, and wonders of wonders, it's slowly charging up. So I'll let it sit for a while and see if it works any better.

I hate to disagree, but I really think it is a capacitor. The markings suggest 3.3v 0.07 Farads.

Interesting .. a capacitor that looks like a battery. I'd call that intentional deception.

I found a post that looked at horizontal accuracy of the ublox 8 with different ground planes (diydrones.com/profiles/blogs/u-blox-m8n-ground-planes-antennas-and-positional-accuracy). The ublox units he tested were in the range of $80. That's probably what a genuine ublox 8 module would cost, although a high price does not necessary mean you don't get a ripoff.

Select to expand quote

decrepit said..

boardsurfr said..
. So the best positioning of the GPS will need some more research.

Peter, reading the link formula posted, I found this.


Mathew also used a ground plane on his version. I think this is worth experimenting with, it may give a significant improvement.

Ok, tried that. Here's the effect of a 7x9 cm ground plate similar to the one above under the GPS module in a stationary test:

Top is speed, bottom is accuracy. Sections are:
Left: on top of GPS with ground plate
Middle: on top of GPS, no ground plate
Right: about 60 cm from GPS, on a wide wood beam.

Maximum speed is 0.5 knots in the middle, and less than 0.2 knots on the sides. SDoP is around 0.35 on the sides, 0.7 in the middle. The large ground plate seems to work quite well. I'll check smaller ground plates later, this one is a bit too large for windsurfing.

If it's a stationary test, doesn't that mean the lower speeds are the most accurate?

For a moment there I had both the dongle and the module working inside.
So I took the GW52 and the module outside to do a stationary comparison.
The module is making a nice big file, but what I'm getting from Samba, GPS results can't open. May be I'm stretching the router wifi limits. I'll bring it back inside and see what I get. well there's hope yet. GPS visualizer can draw the tracks OK!
OK, wifi limit!!! m
Must watch that. GPSResults now open the file with the PI close to the router.

I think I've figured out why the Pi couldn't see the dongle the other day.
Thought I'd be smart and make two dongle entries, and just comment out the one I didn't want. I thought a semicolon, worked the same as a hash, but now I have my doubts, because when I changed to a hash it's working.
Here's what my "wait for dongle" python script looks like now.

def waitForDongle():
dongle = Path("/dev/ttyUSB0")
# dongle = Path("/dev/ttyACM0")
while not dongle.exists():
#print ('- No dongle found ')
time.sleep(4)


I'll now check, the module and GW52 files and see how they compare.
Back later.

Again a stupid old fart attack. I forgot the GW52 is set to 2kts min speed, no data at all from that.

And strange with the module, when I downloaded the file when I first got back up here, GPSResults opened it OK, but after I let it run for a few more minutes it wouldn't.

So now I've set the GW52 to 0kts and stuck them both out on the balcony, so now I'll try the compare thing again.

Not good, they where side by side on the balcony, not an ideal sky view, but the GW52 has +/- around 0.05kts, the module 0.5kts.

Here's the tracks, with 1m grid.




Don't know if it's the cheap Chinese chip or something else, there's the odd point missing in the data as well as the intermittent bad file that won't open.

Interesting. But at least you're getting data . You may see the limits of what a stationary test can do.

The ublox chips don't calculate accuracy the same way as the GW-60. The GW-60 tends to have very low values at low speeds, while the ublox values do not vary much with speed. The GW-60 probably have some logic that limits the SDoP values at low speed. It also does have some coupling between doppler speeds and positional data, so it may well restrict position changes when the doppler speed is low. At least for a while - eventually, it may have to do larger positional jumps, as you can see after crashed jibes.

That said, your accuracy numbers for the ublox look a bit too high. I usually see 0.3-0.4 in my balcony tests. What was the position of the chip relative to the Pi?

Select to expand quote

decrepit said..
If it's a stationary test, doesn't that mean the lower speeds are the most accurate?

You are correct. Lower speed means higher accuracy in a stationary test. Lower sAcc/SDoP numbers mean higher accuracy. The caption was wrong, I should have written "error estimate" rather than accuracy. I can't edit the original post anymore, this is what is should have said:
Top is speed, bottom is accuracy error estimates (+/-). Sections are:
Left: on top of GPS with ground plate
Middle: on top of GPS, no ground plate
Right: about 60 cm from GPS, on a wide wood beam.

Select to expand quote

decrepit said..
Here's what my "wait for dongle" python script looks like now.

def waitForDongle():
dongle = Path("/dev/ttyUSB0")
# dongle = Path("/dev/ttyACM0")
while not dongle.exists():
#print ('- No dongle found ')
time.sleep(4)

If you change it to:

def waitForDongle():
dongle1 = Path("/dev/ttyACM0")
dongle2 = Path("/dev/ttyUSB0")
while not (dongle1.exists() or dongle2.exists()):
#print ('- No dongle found ')
time.sleep(4)

it will work with both.

Select to expand quote

FormulaNova said..
My second GPS module had the capacitor go up to 2.75 volts when running and then down to 2.5 once powered down. From a 'never-used' 0.1mv, I think we can assume its a cap.

I'm using a Beitian BN-220 GPS module (https://www.amazon.com/Beitian-BN-220-GLONASS-Controller-Geekstory/dp/B07BP7LXXD/). It seems to hold the settings well enough (GNSS configuration for > 1 day, baud rate for > 13 hours). Maybe it has a real battery or saves to Flash. The antenna is small (18x18x2 mm), but the reception seems decent (15 sats indoors, SDoP around 0.3-0.4 in balcony tests).

I bought this unit because it does not claim to be a NEO-M8N, since most of these claims are fake. It says it uses a u-blox M8030-KT chip, which is what matters. So far, it seems to work much better than my fake NEO-M8 module that cost twice as much, but more tests are needed.

Peter, the chip was a few centimeters away from the Pi on a shortish lead, the antenna was alongside the module with a small piece of foil under it.
Thanks for the python mod, that will make life much easier!
As yet I haven't got things together enough for a cycle ride, but I'm not far off, that may be a more meaningful comparison.

Think I may have a solution to my intermittent problems. Files that don't open, u-center crashing on some saves and occasional error messages on saving.
Originally I connected the module and converter with wires, but that was awkward to move around, so I decided using the posts would be better.
I had trouble cleaning the small holes after removing the wires, (my solder sucker is at least a 1/4 century old) so I overheated the terminals.
Then the posts supplied with the converter, were too thick to go in the converter holes! I filed them down, and thought they went in easily enough, but when I had a close look, The whole track of RX had lifted, and the round connection at the end broken off, The TX was a bit better only the copper hole had lifted and was alongside the post. I endeavored to connect the RX track to the post with a piece of wire. With glasses and magnifier it seemed I'd succeeded, but thinking of the faults, a noisy/intermittent RX signal would explain it.



Aren't phone camera's great, I get a much better look at what's going on through the lens of my phone than any other way.

So you can see the discontinuity in the R and X letters, this is the lifted track. You can also see the wire I've added sticking out slightly to the left. It looks like my connection here is no where near as I thought it was.

Not sure I've got the skills, eye sight and steady hands to improve this much, but I guess I'd better try.
maybe if I scrape the paint off the track I can get a better soldered connection to it.

That looks rather hard. I'm using screws, velcro, double sided tape, and pins to hold things together for my Bluetooth setup, here's a view from the side:


I messed up a bit on that one, too - the HC-06 bluetooth module (top left) is too far to the edge, so I could not use posts on the left top. But it fits nicely into a GoPro case:


I just ordered a prototype breadboard hat for the Zero W (https://www.amazon.com/gp/product/B01M3SI88S/) to use the same basic ideas for the Pi logger. Ordering all these $10 parts from Amazon is fun - GPS chips, BT modules, screws, cases, Pies, PCB boards, connectors, displays, GoPro cases, solder suckers, solder iron and supplies, and the list goes on. I just hope my wife never adds the cost of all these little orders up.

Yes I had the same thought, only $10 sucks you in, and you get a shock when you add them all up.

And that looks really neat, much better than my mess.

Select to expand quote

decrepit said..
Think I may have a solution to my intermittent problems. Files that don't open, u-center crashing on some saves and occasional error messages on saving.
....

Not sure I've got the skills, eye sight and steady hands to improve this much, but I guess I'd better try.
maybe if I scrape the paint off the track I can get a better soldered connection to it.

Yes, I am finding as I get older that changing the focus to look at small things is harder and harder.

To make it worse, I have been building up my Arduino projects on prototype boards and the tracks are thick, but that makes them close together. Twice now I have had bridges between tracks and have been flat out finding them.

I have to inspect them with a magnifier to check, and even then it is hard.

One of the good things about arduinos is the easy sources of wires and terminals that you can get.

Using the same module as you, I initially used male to male jumpers meant for breadboards. The pins fit perfectly and are easy to solder to. The other end of course goes into the breadboard or can be soldered into something else.

For more permanent installs I prefer single core wire stripped and soldered, and even then Jaycar sell some good stuff for Arduinos that does the job well.

Select to expand quote

decrepit said..
Yes I had the same thought, only $10 sucks you in, and you get a shock when you add them all up.

And that looks really neat, much better than my mess.

What are you guys worried about... in my case its often a case of 'I know I have some of those somewhere' and often do, which shows you how much junk/valuable resources I have stockpiled over the years!

Select to expand quote

FormulaNova said..
What are you guys worried about... in my case its often a case of 'I know I have some of those somewhere' and often do, which shows you how much junk/valuable resources I have stockpiled over the years!

Well I used to be the same, but all my junk was valves and relays.
A few years ago I decided it was time to throw it all out.

This is my TeensyGPS so far. I had it on a breadboard but it became too clumsy when you added things in, as other things became unplugged.




I think with a bit of work I could shrink it down to the size of a toolbox!

Why does it have two GPS modules? I had them lying around.

There's actually extra stuff there, with the final version meant to be just one GPS module, one or two bluetooth modules, and the lithium ion battery with its charging circuits. At the moment I have a serial to USB converter in there to monitor what its doing which won't be needed for the final version.

I am also working on a more practical version which is just a smaller arduino, SD card, one GPS, and one bluetooth module. I am pretty sure I don't need the grunt of this module, although when you compare the slightly higher cost versus the complexity of adding an SD card to a smaller Arduino board, it might be just as easy to stick with the gruntier module.

I need to work on the power consumption. With two bluetooth modules and the default speed of the Arduino, it uses 120mA. Hopefully I can trim that down a bit. I need to run it with the battery and see how long it will run for.

Is this a windsurfing forum?

Select to expand quote

FormulaNova said..
>>>
Is this a windsurfing forum?

It's definitely a fun forum, Great to see what you're both coming up with

Finally found the file I was looking for in the rubbish bin. When I had the module on the seat outside, I was taking the file out of it at odd periods to see how it was going, and it looked OK on GPSResults, so when I bought the device inside and downloaded the final file, I must have deleted the previous ones. BUT, GPSResults can't open the final file, for some strange reason google earth can. So here is a GPSVisualizer view of the long and short tracks, The red one goes haywire as I bring it inside as can be expected under a tin roof.


So is there anyway to view the unloadable file to see if there's any clue why it doesn't load?
I get two error messages when it happens.

Select to expand quote

cannot read from binary file!

no trackpoints found!

Occasionally, you may get empty files, so check the size. But an empty file won't give you tracks in GPSVisualizer.

Easiest thing is if you email the file to me. Maybe I can find out what's going on, and if there's an easy way to fix it.

Here's a short video of two prototypes ready for testing on the water tomorrow:

The left on is the Pi, the right one the Bluetooth GPS. Software is at the "proof-of-concept" level but may be good enough to get some data if the wind plays along tomorrow.

Is that an e-ink display? How good is the visibility outside with that? It looks good.

This is mind boggling!
Now my small battery and otterbox have arrived, ready for moving tests, as soon as either GPS is detected and a new file started the Pi crashes and turns off.
I really get the feeling I'm not meant to be doing this.

Select to expand quote

decrepit said..
This is mind boggling!
Now my small battery and otterbox have arrived, ready for moving tests, as soon as either GPS is detected and a new file started the Pi crashes and turns off.
I really get the feeling I'm not meant to be doing this.

Don't be disheartened. Its a learning experience. Sometimes though you can find things that just don't want to work together, even when they should. I am staying away from Rpi solutions as it takes more than my knowledge to understand how it all works. At least with the Arduino stuff its pretty basic.

What are you guys using for powersupplies for the Raspberry Pi?

I have ended up with a combination of modules and a lithium ion battery. You can get generic Li-Ion charging modules that also have a low-voltage cutout, but they deliver the battery voltage through to the load, which can be 4.2v or down to 2.5v, so normally not useable to power an Arduino.

So, I have then coupled that with a '5v UPS' that boosts the voltage back to 5v to power the Arduino... which runs at 3.3v anyway.

I have some buck/boost 3.3v modules on order from ebay, as it needs to be a boost circuit when battery voltage is low, and a buck circuit when battery voltage is high. 3.3v is what I really need as the Arduinos I am using have onboard regulators to 3.3v anyway, so its more efficient to just deliver the correct voltage instead.

The benefit of these modules is that they are dirt cheap and can provide good functionality. The disadvantage of these types of modules is that they don't tend to come with much in the way of instructions and in some cases no description of what each terminal does. So, for the charging circuit I had to run it up with a variable power supply instead of the battery connection, just to find out if it has a low voltage cutout, which is essential for not killing Li-Ion batteries. It turns out they do (I have two different modules of essentially the same circuit), and the cut-out is 2.5v.

So, I then had to run the 5V UPS module with the same power supply to see what it does, and it turns out it is able to provide 5v all the way down to a 2.1v input.

Without trying this, I wasn't even sure the charging modules had low voltage cutout and if the boost module could cope with the low voltage. The good news is that I can set the Arduino to measure the supply voltage and effectively shut itself down at 3.3v or so, which is essentially the limit of what you really should draw from the battery, and if it keeps getting lower the circuit cuts it out before it can damage the battery.

I guess it has some benefits over using a power-bank type setup, in that in theory I have more power available and I can use pretty much any lithium ion batteries I can find.

Select to expand quote

FormulaNova said..
Don't be disheartened. Its a learning experience.

It's not so much that I'm getting disheartened, it really does seem that I'm being given a message, and the more I ignore it and persevere, the more I get knocked back.
I bought a some 3.5* close up specs today, and with them I can see what I'm doing, so I'll possibly get sucked in to try and re-solder the converter

My main objective was to help with testing for evaluation purposes, but at the moment it seems all I'm doing is highlighting all the things that can go wrong. It's certainly not giving anybody else encouragement to have a go themselves.

After Fangy failed with his Arduino attempt, and somebody made the comment that the chips were too slow for the needed speeds. I thought the Pi a better alternative. I'm reasonable familiar with debian based linux, but have no idea what's inside an Arduino.

Select to expand quote

decrepit said..

After Fangy failed with his Arduino attempt, and somebody made the comment that the chips were too slow for the needed speeds. I thought the Pi a better alternative. I'm reasonable familiar with debian based linux, but have no idea what's inside an Arduino.

It's not that the Arduino chips are too slow, it more that programming them is trickier. You have a lot less resources to work with, and you need to know what you are doing. The guy who developed the FlySight managed to even get speed announcements into his firmware, which was no small feat. But I played with his code, and I knew developing something like this would be no fun for me, and have a high chance of failure. The Pi is easier because it has about 100 times more RAM etc., and supports any language you want to program in. The chip is plenty fast, it does not seem to miss data points even when also updating the display (using Python, which is easy but needs more CPU).

Even the FlySight guy gave up when he ran into issues with RF interference and waterproofing while trying to get a 10 Hz version for windsurfing, and I think he has an EE background. KISS and go slow - plugs, then breadboard, then connectors or solder, with plenty of testing in between. It's a slow process but fun.

Select to expand quote

decrepit said..
This is mind boggling!
Now my small battery and otterbox have arrived, ready for moving tests, as soon as either GPS is detected and a new file started the Pi crashes and turns off.

Could be a battery thing. If it's a USB battery, they tend to turn themselves off after 30 seconds of low load, which may well be what you are seeing. The Pi uses more power when starting up, and when a WiFI network is in reach, which is confusing and makes it hard to see what's going on. If it does not happen when the Pi is on a power supply, that's probably the reason.

I ended up using LiPo batteries for both current prototypes. For Bluetooth, I use it directly, since both GPS and HC-06 can take 3 to 5 V. For the Pi, I used a circuit from Adafruit (www.adafruit.com/product/1944). It's somewhat expensive ($15) and lacks a switch, but works and is easy. I'm using 500 mAh and 1200 mAh batteries, respectively - good enough for > 5 h sessions (I hope).

Select to expand quote

decrepit said..

FormulaNova said..
Don't be disheartened. Its a learning experience.

It's not so much that I'm getting disheartened, it really does seem that I'm being given a message, and the more I ignore it and persevere, the more I get knocked back.
I bought a some 3.5* close up specs today, and with them I can see what I'm doing, so I'll possibly get sucked in to try and re-solder the converter

My main objective was to help with testing for evaluation purposes, but at the moment it seems all I'm doing is highlighting all the things that can go wrong. It's certainly not giving anybody else encouragement to have a go themselves.

After Fangy failed with his Arduino attempt, and somebody made the comment that the chips were too slow for the needed speeds. I thought the Pi a better alternative. I'm reasonable familiar with debian based linux, but have no idea what's inside an Arduino.

Yes, sometimes things are more complex than a normal DIY project, but hopefully its interesting for you as well.

I didn't see the earlier conversations about DIY GPS with Arduino, so I am curious about why these stalled.

I think Arduino chips are fast enough, but from what I have read it looks like writing to SD card was a problem for some and its seems like you can work around that by pre-allocating files. The SD cards seem to have a bit of a slow down when you are writing to them and then they need a new block to write to, which introduces a non-trivial delay. With the small amount of memory on an Arduino you can't really buffer the data while all this is happening.

I think the pre-allocation of files is the answer to that, which is not even really a drawback, just another task that you need it to do before you create a session. It even makes sense in that you are effectively reserving blocks of storage for a session, and even for a Kato endurance run, reserving SD blocks shouldn't be a problem.

I am approaching the problem a bit differently. The Arduino I am using is more like the RaspberryPi than a normal Arduino. It has a fast processor and heaps of memory, but uses Arduino coding. For me that makes things easier to understand.

When I finally get around to trying to log data it will be interesting to see what issues I get. I suspect that this particular board will be sitting idle for most of the time as storing data at 115.2k is not such a big ask.

In parallel I want to run up the same idea on a regular Arduino type processor and see if I can hit a limit with that.

Select to expand quote

boardsurfr said..

decrepit said..
This is mind boggling!
Now my small battery and otterbox have arrived, ready for moving tests, as soon as either GPS is detected and a new file started the Pi crashes and turns off.

Could be a battery thing. If it's a USB battery, they tend to turn themselves off after 30 seconds of low load, which may well be what you are seeing. The Pi uses more power when starting up, and when a WiFI network is in reach, which is confusing and makes it hard to see what's going on. If it does not happen when the Pi is on a power supply, that's probably the reason.

I ended up using LiPo batteries for both current prototypes. For Bluetooth, I use it directly, since both GPS and HC-06 can take 3 to 5 V. For the Pi, I used a circuit from Adafruit (www.adafruit.com/product/1944). It's somewhat expensive ($15) and lacks a switch, but works and is easy. I'm using 500 mAh and 1200 mAh batteries, respectively - good enough for > 5 h sessions (I hope).

Yes, I agree. You could rule it out by comparing the behaviour with a regular powersupply.

The adafruit circuit seems like the way to go. For that price it removes all the headaches.

My approach just seems like the more complex way to achieve the same result as the Adafruit board, albeit made up of cheaper modules from ebay. I am testing around a regular 18650 cell at 2600mAh and its bigger brother at 3400mAh. So unless I create a fire by shorting the batteries, it should give me decent battery life.

I also had the battery thought so I tried with the "official" pi power supply, same thing, It's an instantaneous shut down as soon as the new file is created, I don't even have the time to see it happen, but the new file is there when I reboot.

But thinking about the sequence now, may throw some light. It all started after I used Peter's modified python script to choose between 2 GPS's.
I didn't have the monitor, mouse or keyboard connected, just using samba to look at pilogger.
I wasn't getting a new file created with either device, but the Pi did shut down a while after the GPS was removed.
So I new the GPS had been detected because the shut down sequence worked.

Then I changed back to the original python script, plugged in TV, keyboard and mouse, and then got the instant shut down after the dongle was detected. So maybe it is a current draw issue and I should try it again with out keyboard and mouse.