It might not be clear from my pics, but each wire lies inside its own duct (see posts 54 & 50). They can’t make contact with any other wire.
3 Likes
Hi John
In the short term probably not. In the long term I couldn’t say for certain. Probably a lot depends on environment as to how long bare copper takes to deteriorate. I personally would use tinned wire throughout as a thing of habit. During my working life I suppose I just got used to some very fussy customers who laid down some pretty tight specs. In almost all cases for a good reason. One almost universal spec comes to mind which stipulated “there shall be NO exposed unprotected bare metal.” This meant copper, aluminium, steel, all metals. Indeed if you used the incorrect tool on a nut or screw and damaged the plating the item had to be replaced (using the correct tool).
One article in the AWA Standard Practice Manual stated that when fitting a through hole component to a PWB (“PCB” was not used as “PCB” is a cancer causing agent in the old oil filled paper capacitors) the component lead was to be cut prior to the soldering operation. This was for 2 reasons. 1) this reduced the risk of dry solder joints caused by any heat sinking effect of the extra lead and 2) The soldering operation provided a protective film of solder covering the exposed metal of the component lead.
All the above was laid down by persons far smarter and on a substantially larger pay scale than me so let us say I just believed them and tried to make sure I did not have to do anything twice.
It just seemed a shame that after presenting a brilliant project such a little thing at the end has the potential to spoil it a bit. For me anyway but there again I might be a bit fussy.
Cheers Bob
5 Likes
I now understand.
Thanks for the background. I get a buzz from the history of technology and manufacturing. During lockdown I watched many historical youtubes about this. It seems that alot of film material has become declassified or made public especially from the WW2 period. I watched some on high reliability soldering because you raised the subject. I was inspired to have a go at making something of quality.
I understand the importance of hi standards for mass produced products that need to last a long time in unpredictable environments. The biggest weakness with my device is the plastic the housing is made of. It is PLA plastic. It softens in heat. If left on the dash in hot sun it softens and sags. It would still work, but would be an interesting shape.
There was a pragmatic reason to use stripped wire. I would prefer to use insulated hookup wire but have some work to do to make it 100% easy to work with. I’m aiming to make a design that anyone can build without a struggle. At the moment the struggle is in the assembly. I’ll get there.
Thanks to everyone who has shown an interest.
John.
3 Likes
Hi John
Might take up the shape of the dash. Stop it sliding around. Could be a marketing point.
And I am sure you will. If someone has to make it, assembly is all important. A lot of thought has to go into it. That is why manufacturing companies used to (don’t know about the present day) have model shops, the interface between design and practical production. All important.
Cheers Bob
2 Likes
It would be interesting. Might look like those paintings of melting clocks Dali did.
Today’s buzzword is “UX” – User Experience.
3 Likes
I’m new to the party and might have missed something, but why dont you just use solder through enamelled wire?
I’ve used it on a load of projects and there’s no issue with them touching each other as they are insulated.
3 Likes
Hi Andrew.
I haven’t worked with enamelled wire. Looks like it would require a few extra skills.
The first design I built used insulated jumper wires or single core insulated hookup wire. The problem was the tight spaces I had for soldering to the boards. Making the wires longer alleviates that but they have to be crammed into the box when I position the boards and they push back like springs.
So now I’m trying an approach that exploits the capabilities of 3D printing. I can create tiny tubes that form ducts, or conduits, for each wire. Instead of a box with open sides, it is solid. Each duct runs from thru hole to thru hole. Wiring the boards up is easy as the wires emerge from the ducts precisely at the correct thru holes. You can’t make a mistake with the connections.
What I need to sort out is whether to use insulated or bare copper wires. It’s not always easy to insert a wire all the way thru the duct. Sometimes insulated is easier than bare and vice versa. I’ve nearly got it mastered though.
The end result is good. Each board is tight & flush against the housing. The wires are hidden and safely separated from each other.
Some pics of the finished job (and it works!):
5 Likes
Enamelled wire is no different to use, you just need to tin the ends until the enamel burns off, you’ll know when it does it kinda bubbles.
Ive used it instead of insulated wire in similar situations to you where I needed to pack a few wires into a small area, in fact I am in the middle of a new project where Im using it for the exact same reason, insulated wired wont fit.
Your solution looks good and you seem to be done, so there’s probably no need to change, it would be just giving me the willies knowing that I had uninsulated wires in there 
3 Likes
But they are insulated, just not with the original PVC. Each wire is sheathed in PLA. The only uninsulated parts are at the ends where they are soldered to the boards.
4 Likes
Hi John
Nice GPS learning exercise for me. Thanks for writing it up as a project. Lot of work getting there from you. I’m probably going to have a go at it. Just printing the monobloc at the moment to see how it goes and if ok will try threading the wires. One question I have is about powering the device. I note you are not using a logic level converter as per the recommendations on the GPS module page, I’m not sure how you get away with it with Rx connected to the 5v nano, but am I right in concluding from the sketch that Rx is never actually used even though its connected and the nano is only listening to the module on its Tx connection? I guess there is no reason to be sending the GPS module anything or am I way off track??
4 Likes
Hello Roger.
Thanks for those comments and having a go at printing the monobloc. Call out if you have any problems.
I haven’t included any logic converter and your’e right, only the GPS TX pin is used as I’m not sending any config commands to the GPS from the Nano. I’m not certain, but the board might take care of it for the GPS RX connection. It certainly allows you to use 5v power supply from the usb connection. Remember that the board is not made by ublox. The board’s maker has included a voltage regulator that supplies 3.3v to the ublox chip. You could omit the wire from GPS RX to Nano TX and the device would work just the same.
I’m looking forward to hearing how you go. Post some pics as you go.
Cheers,
John
3 Likes
Hi John
Thanks for replying. I’ve been waiting on a few parts and still waiting for my nano board which is on backorder but I have made some progress. From further reading I think you are correct about the receiver board protecting the uBlox chip, including its Rx/Tx pins from over-voltage. This is confidently stated in one online guide for the board.
I printed your monobloc and it went well. I was able to feed 0.7mm fishing nylon through all the channels and having finally got hold of some 0.5mm copper wire that I’ve confirmed goes through ok too. The GPS receiver I got from a different supplier must come from a different manufacturer because it doesn’t quite sit properly in your antenna holder. I think its about 1mm narrower and it falls through, so I think I’ll have to modify the holder slightly. I’ll do it in Rhino3D which I’m well used to, as I haven’t used Tinkercard for any design work.
In the interim I stuck the antenna to the receiver with some double sided tape across the center and it seems good and firm. I’ve got the device sitting on a breadboard with a UnoR3 and when I tested it using test sketches from the tinyGPS github site, to my surprise and delight they all worked immediately. Got a fix within seconds and found 16 satellites. It located me to within a metre or less of where I was sitting according to visualisation on google maps, and accurately measured me moving just 10 metres away to another spot. Must be beginners luck as I was expecting it to be tricky after reading about others’ experiences.
I also hooked the receiver up to u-centre directly with a TTL to USB adapter and that all worked immediately as well but only after sorting out a very weird issue with the COM port interacting and interfering with my mouse. The mouse was jumping all over the show and after initially having a GPS fix that I lost, the COM port I was using was greyed out in u-centre. Anyway, with vital help in a solution from another online forum, a simple registry edit for the mouse driver fixed it and all has been fine since. This problem seems to have been associated with FTDI TTL to USB adapters.
Unexpectedly, when I took my laptop and the receiver back inside to my desk, it continued to receive data from 6 satellites! Not sure how that works downstairs in a two storey house, but it does. Maybe the signal is sneaking in the windows, which are at least 3-4 metres away??
I put the TM1637 display through a test process and that’s working fine too, along with my peizo buzzer. Today I rigged up your circuit on a breadboard with my Arduino Uno and got your sketch to compile after adding in a couple of missing libraries (TM1637 and SoftwareSerial) but when running it, my display only shows “0”. The monitor indicates that the sketch is deriving the UTC and speed from the first two messages received but in my case these are not RMC & VTG, but are GLA and GGL (see images), so the UTC time and speed I need are not being picked up correctly. I don’t know what determines the message sequence but if this is consistent then I can recode the sketch to fit this, or maybe use the GPS library which seems pretty easy to use. Anyway, that’s where I’m up to now. I’m now just waiting on the nano so I can try to build it on your 3D print chassis. Looks like that’s probably still 10 days or so away, most of which I’ll be away from home anyway and hopefully it’ll be here when I get back.
2 Likes
It can be surprising how well GPS signals can get through sometimes. I was testing some GNSS antennas inside a brick buiding with no VLOS through windows and was able to get a solid signal from 6 satellites and a signal from 16 in total.
1 Like
Thanks Aaron. Yes it was certainly a surprise to me in my first foray into GPS electronics (outside my car navigation). I’d thought it had to pretty much be line of sight but obviously not. So much to learn!
1 Like
I am now getting UTC and speed logged on the serial monitor and on the LED display. 
I tweaked the sketch as below to capture the required data because RMC and VTG are consecutive but not the first two sentences I receive. I subsequently took it for a drive and it was displaying my speed as intended. 
while (mySerial.available() == 0) {};
while (!timeout) {
while (mySerial.available() > 0) {
sentence = (mySerial.readStringUntil('\n')) + '\n';
if(sentence.substring(3,6) == "RMC") { RMCsentence = sentence; }
else if (sentence.substring(3,6) == "VTG") { VTGsentence = sentence; }
Serial.print(sentence);
markTimeLastCharRead = micros();
}
//no data avail., timeout?
elapsedTimeSinceLastCharRead = (micros() - markTimeLastCharRead);
if (elapsedTimeSinceLastCharRead > GPStimeoutDuration)
timeout = true;
}
Now to get it into your monoblock based package John …
4 Likes
Hey, Roger. Well done!
I’m thrilled you’re doing this – as far as I know you are the first person to try to make the device. Lots of folks have copied the antenna holder so that must be a common issue.
I’m pleased my sketch is clear enough that you can tweak it to get the speed and time from your module’s output. All the modules I’ve used outputted the same GP messages by default. Yours appears to be accessing the Beidou system (Chinese, $BD messages) and the Glonass system (Russian, $GN messages) as well as the GPS system (USA, $GP messages).
The modules can work just fine indoors. Over on the Arduino forum there are some people who insist you have to be outdoors with a clear view of the sky. Not so.
My most recent module (from Core) worked beautifully straight away like yours, but over time its performance has deteriorated. I don’t know why, but I do think it’s best to handle them as little as possible. That’s why I designed the antenna frame so there’s less need to touch the antenna.
Are the conduits easy to understand? I’ve worried that the images I provide in the project are not at all clear to others. The concept is difficult to convey in words.
Are the pinouts on your module the same as in my project?
3 Likes
Hi John
I found the conduits easy enough to understand. Just took a bit of patience and close examination of your images and the Tinkercad files. It was all very clear once I had printed the monobloc and poked some fishing nylon through them all with one eye on your schematics, layouts etc. The pinouts on my GPS module are the same. It looks identical other than the slight difference in board dimensions.
I was having some trouble getting the time to display consistently at low speed. It was doing it but only intermittently and I convinced myself it was a timing issue. Not sure if the Uno I’m using is faster or slower than the Nano. Having tested my module with TinyGPS++ example sketches, I decided to try your logic flow with TinyGPS, which was easy and seems to work really well. Fairly compact code as you can see below.
#include <TinyGPSPlus.h>
#include <SoftwareSerial.h>
#include <TM1637Display.h>
// GPS Receiver
TinyGPSPlus gps;
static const int RXPin = 3, TXPin = 4;
static const uint32_t GPSBaud = 9600;
SoftwareSerial ss(RXPin, TXPin);
// TM1637 LED Display
#define pinCLK 12
#define pinDIO 10
#define brightnessNormal 5
TM1637Display display(pinCLK, pinDIO);
// Peizo buzzer
#define pinBZR 6
// For displaying local time
int Local_time, Local_time_LED;
int UTC_offset = 12;
int DST = 1; // Daylight Saving Time, 0 = No, 1 = Yes
void setup()
{
Serial.begin(115200); // for serial monitor only
ss.begin(GPSBaud);
Serial.println(F("GPS Speedo"));
Serial.println(F("based on sketches by Mikal Hart (TinyGPSPlus) and John74406 (Core Electronics Forum)"));
Serial.println();
pinMode(pinBZR, OUTPUT);
tone(pinBZR, 2000, 100); // sound buzzer to confirm startup
display.setBrightness(brightnessNormal);
display.showNumberDec(8888);
delay(500);
display.clear();
}
void loop()
{
// Dispatch incoming characters
while (ss.available() > 0)
gps.encode(ss.read());
if (gps.time.isUpdated() && gps.speed.isUpdated())
{
Local_time = gps.time.hour() + UTC_offset + DST; //UTC offset plus DST adjustment
if (Local_time > 23) {Local_time = Local_time - 24;} // 24hr clock
if (Local_time > 12) {Local_time = Local_time - 12;} // 12hr clock
Local_time_LED = ((Local_time * 100) + gps.time.minute());
if (gps.speed.kmph() <5)
{
display.showNumberDecEx(Local_time_LED, 0b01000000, false, 4, 0); // display time on LED
delay(1000);
display.showNumberDec(gps.speed.kmph()); // display speed on LED
delay(1000);
}
else
{
display.showNumberDec(gps.speed.kmph()); // display speed on LED
}
}
}
I’m keen to be able to display altitude as well, and I might subsitute time with altitude. This is also very simple with the TinyGPS library.
I’ve been away for a week so no progress on the rest of the 3D printing yet and I’m still waiting for my Nano which is still on backorder. Probably should have purchased a compatible clone alternative but I’m not in any great hurry.
3 Likes
Hi Roger. Well done, again. You’re moving from the theory to the practical. You’ll find there’s a few surprising issues.
With the vehicle stationary, don’t expect the GPS to give you a steady zero kph – it’ll jump around quite a bit. There’s a random component to the positional computation from cycle to cycle. It can give you a significant speed even when stopped. U-center has a view that shows a plot of your location and it never stays static even if you are stationary. It’ll jump around by several metres. This is an inherent characteristic of the GPS system and you can’t adjust for it other than reject obviously sporadic values. I find that it is not a meaningful issue at speed.
When you start doing things with the GPS data, timing does become a real issue. You need to have an understanding of how much time different actions use up. Sending a value to the TM1637 takes significant time. Same with sending text to the IDE monitor. The serial channel (both hardware and software serial) have a 64 byte buffer. If the GPS is transmitting while the sketch is sending to the TM1637 or the monitor, the buffer is likely to overflow and that gives corrupted sentences and you have to deal with that.
I’ve never made use of the altitude. It’ll be interesting to see how that goes for you. Course is a handy piece of information.
Don’t print the case until I make a small mod. Mine has shrunk just enough to be too narrow to insert the monobloc. I’ll make the opening a little bigger.
Did you order the Nano with the header pins soldered in? My design requires header pins although you can use it without – you solder the wires to the Nano which makes it not easy to take apart.
3 Likes
Hi John. I finally got around to “threading up” the monoblock and assembling it. Its all working! I used silver wire since I had some around and its an excellent conductor. The copper wire I got was smothered in enamel or something and I couldn’t be bothered stripping it. Threading the conduits wasn’t too difficult but setting them in with the soldering iron had a bit of a learning curve. Easy to overdo it. In retrospect I realised I should probably have extended the wires through the pin channels and not just stopped at their entrances, but at this stage the connections seem ok.
I’m not using the antenna mount at the moment because I used another GPS module (same type) which was different in dimensions again. The antenna is well attached with some double sided tape and the module seems pretty stable on its pins. I’ll draw a mount up for it along with an outer case and print them soon and it’ll be all done! Thanks for your project guide and other advice. I know a lot more about these receivers now than I did a couple of months ago. Alongside this I’ve also built a GPS logger with an LCD display of Lat, Long, Speed, Altitude, and Satellites fixed. I’m keen to take it on an upcoming off-road trip next month so I can have a better idea where we’ve actually been!? I’ve attached a few images of the logger as well as of your design piece, showing the initial unfixed conduit threads, and with the sketch running showing speed (0) and time at low speed
. I printed the logger case with ASA filament which is very UV stable and I hope will mean it will last a few trips up under the windscreen of the car. I can load the log file into GPSVisualiser and get a map and elevation profile of the trip in a flash. I have the same type of GPS module from a couple of different sources and in addition to slight variations in size, they also differ in network channels received and some data. The one in my logger doesn’t get geodic separation (receives it as 0.00) in the GGA sentence so the altitude is way out but I’ve now got the sketch subtracting the local 37.72m geodic height and the altitude is now matching expectations.
6 Likes
Roger, I’m thrilled to bits to see my design reproduced by someone else and working – you’re the first.
You have been busy.
1 Like
