BaltasarParreira / Icetube_Clock_NTP

NTP to GPS for Icetube clock using any ESP8266 or ESP32
1 stars 0 forks source link

Can not compile due to GeoIP error #1

Open bnevets27 opened 9 months ago

bnevets27 commented 9 months ago

First of all, thank you for creating this! I'm attempting to use it with an entirely different nixie clock. I'll update this when I know if it works.

I am new to compiling arduino code but I did mange to get this all setup and compiled. But I did run across a couple issues.

When trying to compile I got the following error: 'struct IPGeo' has no member named 'abbreviation'

So I commented out/removed line 207: TZID += "<br>" + IPG.abbreviation;

I got another error with the IPGeolocation.cpp file, along the same lines, referring to "abbreviation". So I looked at your commits to IPGeolocation.cpp, specifically this one

And I removed line 93: I->abbreviation = timezone["abbreviation"].as<String>();

I was then able to compile and get it on my esp8266.

bnevets27 commented 9 months ago

Well I got the esp8266 up and running. Very slick. Got it wired up to my clock but unfortunately the time doesn't update. I tried different baud rates but it didn't help. Not sure if there is something glaringly obvious I missed. This is the clock that I have

BaltasarParreira commented 9 months ago

Hi, yes sorry... I missed that variable here when I committed my IPGeolocation version with the extra fields/information. Code updated now so it should compile ok without the need for removing what you reported.

Regarding the NIXIE clock from PV Electronics, I have not the exact same model but other similar from them, so did you not forgot to turn the GPS on on the clock menu?

Di you upload the files from DATA folder with the right variables filled in, mainly key.txt for IPGeolocation and them on the ESP8266 menu put your registered key?

Other thing is checking on the Arduino IDE serial interface if the GPS lines are working and showing info every second with the debug Serial.prints on.

Thanks.

bnevets27 commented 9 months ago

Great! I was able to compile now with line 207 restored.

I've set the following parameter on the clock: Parameter 12 = 4 (GPS) Parameter 13 = 1 (I tried other baud rates, not sure which baud rate this code is using) Parameter 17 = 0 (No DST offset)

RFT indicator LED (D9) is off. But that is a bit confusing as if Parameter 12 = 0 (GPS Off), the LED is off, but it is also off if Sync > 24 Hrs. (I haven't had the clock running for a full day yet)

As for the esp8266 (I'm using a D1 mini clone). I did upload the DATA folder. I added the abstractapi.com key via the web interface at "http:///setup".

I did use the Arduino IDE serial interface and saw it write the key info and then it updated the webpage with IP Geo info. I'm also am seeing the GPS lines printed every second.

I wired the esp8266 to the clock as follows: NixieClock --------> ESP8266 GND ------------------> GND 5.2V ------------------> 5v (VIN) GPS IN -----------------> TXD

Output of Arduino IDE serial interface, with personal data redacted.

Starting
*wm:AutoConnect 
*wm:Connecting to SAVED AP: xxxxxxx
*wm:connectTimeout not set, ESP waitForConnectResult... 
*wm:AutoConnect: SUCCESS 
*wm:STA IP Address: xxxxxxxxx
Connected...yeey :)
Reading file: /key.txt
- read from file:
{"ip_address":"xxxxxxx","city":"xxxxx","city_geoname_id":xxxxxxxx,"region":"xxxxxx","region_iso_code":"xxx","region_geoname_id":xxxxx,"postal_code":"xxxxx","country":"xxxxx","country_code":"xxxx","country_geoname_id":xxxx,"country_is_eu":xxxx,"continent":"xxxxx","continent_code":"xxxx","continent_geoname_id":xxxx,"longitude":xxxx,"latitude":xxxxx,"security":{"is_vpn":false},"timezone":{"name":"xxxxxx","abbreviation":"EST","gmt_offset":xxx,"current_time":"xxxx","is_dst":xxxx},"flag":{"emoji":"xxxx","unicode":"U+1F1E8 U+1F1E6","png":"https://static.abstractapi.com/country-flags/xxxxx.png","svg":"https://static.abstractapi.com/country-flags/xxxx.svg"},"currency":{"currency_name":"xxxxx","currency_code":"xxxx"},"connection":{"autonomous_system_number":xxxx,"autonomous_system_organization":"xxxxx","connection_type":"xxxx","isp_name":"xxxxxxx.","organization_name":"xxxx"}}
xxxxxx
xxxxxx
xxxxxx
xxxxxxxxx
xxxxxxx
0
xxxxxxx
xxxxxxxx
xxxxxx
xxxxxxxxxxxxxxxxxxxx
https://static.abstractapi.com/country-flags/xxxxx.png
DST=-5.00
TZID=xxxxxx<br>xxxxxxxxxxx<br>EST<br>DST is Off
DST_TIME_OFFSET=xxxx
HTTPUpdateServer ready! Open http://icetube-ntp-clock.local/update in your browser
$GPRMC,143736.00,A,xxxxx.xxxx,N,xxxxx.xxxx,W,xxxxx.xxxx.1,220124,,,A*44
$GPRMC,143737.00,A,xxxxx.xxxx,N,xxxxx.xxxx,Wxxxxx.xxxx.1,220124,,,A*45
$GPRMC,143737.00,A,xxxxx.xxxx,N,xxxxx.xxxx,W,xxxxx.xxxx.1,220124,,,A*45
$GPRMC,143738.00,A,xxxxx.xxxx,N,xxxxx.xxxx,W,xxxxx.xxxx.1,220124,,,A*4A
$GPRMC,143739.00,A,xxxxx.xxxx,N,xxxxx.xxxx,W,xxxxx.xxxx.1,220124,,,A*4B
BaltasarParreira commented 9 months ago

Ok good, but you forgot one important thing. The Nixie clock expects the serial TXT to be 5v, ESP8266 works and sends it with 3.3v, you need a level shifter circuit in between the two. Something like this: https://www.sparkfun.com/products/12009

You only use 1 of the 4 ports that has it, the Arduino RX in this example from the D1 TX (imagine the Arduino Uno as your Nixie clock and the Raspberry Pico as your ESP8266): image

Regarding the BAUD, my code uses 9600.

bnevets27 commented 9 months ago

Thank you!!! That is a very important thing I forgot/didn't think about. I'll order a level shifter and wire that up. Hopefully that's the only issue and I suspect it is. Excited to get this working.

bnevets27 commented 8 months ago

Well I got my level shifter finally. Still can't get the clock to update the time sadly. Everything looks right. The esp is sending the GPS lines via the serial output. The output of the level shifter/ GPIO2 (D4) is going high and low. The clock is set to 9600 baud.

This is how it's wired: image

I also tried using the 5v from the D1 mini. The D1 output is about 4.5v while the clock is 5.2v. But since the clock has a transistor, I don't think it really matters anyway.

BaltasarParreira commented 8 months ago

Hi, wiring looks ok.

You can use the clock 5.2V to power the D1 on his 5V pin.

Things I'll check first, measure the voltage in between the HV1 and GND should be around 5V, then the same but on LV1 and GND should be around 3.3V.

If all that ok I revise the GPS clock settings menu, that according your manual should be: image image image

When you say is not working what's really happening?

The GPS led turns on? Blinks? Anything according this: image

Check with PV Electronics if the NIXIE clock needs other GPS messages apart the only one my code sends: image

It might need the $GPGGA message that tells that the GPS is locked/fixed and use it for the different led status as showing on GPS led image or any of the other messages.

UPDATE: I just found that at PV Electronics they have now the exact some idea, a fake GPS signal module, this one: https://www.pvelectronics.co.uk/kits/NTP/wifi_V3.pdf

Looking in that information it only mention the $GPRMC message, but I wonder how they connect the serial part since they power the module from the NIXIE clock, I can see from the photo that the board as a regulator for getting the 3.3V from the 5V connected, but I cant see nothing on the exit TXT port for handling the voltage difference and since they don't supply the circuit diagram is difficult to check further.

bnevets27 commented 8 months ago

First, I really appreciate your help trying to get tis to work. I am really hoping to breath new life into my clock as it never kept time well so it has spent most of it's life turned off.

I wasn't sure if the D1 mini would pull more current then the clock was able to provide as the manual says they allow a max 50mA for the GPS module. Long term I do have other plans and may end up tapping into the 12v and regulating that down as another 5v source. For now the D1 is powered via the USB or plugged into my computer to read the serial log.

Voltage between the HV1 and GND = 5.2v Voltage between the LV1 and GND = 3.3v

I do have option 12 set to 4 and option 13 set to 1.

When you say is not working what's really happening? Time doesn't update just stays at the time it started counting from when it was power on, which is 12:34. So about 5hrs later and now it shows 4:57.

As for the GPS LED, it seems to me the design of that logic was poorly thought out. The GPS LED on my clock is off. Which, according to the manual can mean either the Radio Time Source = None or that I do have the GPS source but it hasn't synced in over 24 Hrs. Since I don't know the sync schedule I'm not sure how often it should be syncing. One would assume relatively frequently, but to be sure I've left the clock on for over 24hrs and it hasn't synced and the LED is still off.

I had reached out to PV Electronics earlier but I didn't receive a response. Now that I know a bit more and are more sure everything is correct electrically and programing wise I am working on reaching out again.

The only info I have to go off is the manual you have also read. I had hoped and assumed since it mentioned the GPS module that's compatible has an output protocol of $GPRMC. So I figured it would likely be compatible with your software.

I did come across the PV Electronics fake GPS signal module, which had also given me hope your code would work. One of the reasons I didn't get that is it's not listed or designed to be compatible with this clock due to the different connector. I had hoped they didn't change how that talked to clocks since. I also wanted to use this project and build me own instead. Sorry I didn't included that before. It slipped my mind that it may have provided helpful info.

As for how they are handling the TXT voltage. I wonder if they are actually using 3.3v instead of 5v. Only reasons I suspect that is the manual mentions the clock will accept other GPS modules with output signal levels of RS232 or TTL. So maybe there's a chance they are using TTL at 3.3v ? On this clock at least they are using a MPSA42 on the RX (Pin 5). But you would know better than I.

BaltasarParreira commented 8 months ago

Hummm, do you have a FTDI interface that can handle 3.3V TXT signals? The idea is debug and check if something is really getting out from the D4 pin using a second USB port connected to the FTDI board and with some king of terminal software with 9600 settings check what's passing. Could be that for some reason the second serial port implementation on your D1 mini is different, uses another pin or else.

Also you can do another easier test, that is on my code comment all Serial. commands so you loose debug messages on Arduino and change all the other Serial1. existing commands to normal Serial., like this you can connected the D1 mini to the NIXIE clock using the normal serial TXT pin instead the D4. I think with this you also could see on Arduino IDE what's being sent if you change the serial on the IDE to 9600 using the USB connected to your PC as you have now. This is just for debugging if messages are really good passing. If they look ok I recommend when you connect the TXT to the NIXIE just use a normal phone charger to power the D1 mini board and avoid any serial interference because is connected to the PC using or not the Arduino IDE.

bnevets27 commented 8 months ago

I tried a couple things. The end result is; with a FTDI adapter plugged in to the level shifter (I used the 5v mode of my adapter) I'm able to read the serial output via the D4 pin at 9600 baud. I did try the other troubleshooting you mentioned but I think this is the best proof everything is working as intended.

For clarification I was powering the D1 via the usb via a phone charger and not the computer to avoid it causing any interference.

I think you hunch that:

It might need the $GPGGA message that tells that the GPS is locked/fixed and use it for the different led status as showing on GPS led image or any of the other messages.

Is likely the issue or something along those lines.

I'll reach out the PV Electronics and hope they actually respond. I'm a bit doubtful. But we'll see.

Again I really appreciate your help getting this working. Everything but the clock is working as it should be now.

BaltasarParreira commented 8 months ago

Ok, another debug so you can check that the level shift board is working also. Using the FTDI do the same test connecting it to the HV1 and GND and see if messages are ok too.

Meanwhile let's hope PV Electronics give us some light, but as soon I get time I will investigate a way of my code sends a GPS lock/fix message too, I just think I need some specific timings that I don't know yet.

UPDATE: Doing a quick find I found this other code on GITHUB, you can try it also to see if it works for you. Strangely they connect the ESP8266 directly to the NIXIE clock without any level shifter so maybe depending the type of clock it can handle the serial at only 3.3V.

Anyway here is the link so you can do your tests: https://github.com/xSnowHeadx/FakeGPS

NOTE: Also read this on that link, looks like some clocks need some special message format/values, could also be the problem: https://github.com/xSnowHeadx/FakeGPS/issues/1

FINAL UPDATE: Looking further on the information they provided from that GITHUB pages you can also try this (either one or the other change at line 594 of my code): msg = cmd + delim + finaltime + ",A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",,,D" + splat; or msg = cmd + delim + finaltime + ".000,A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",,,D" + splat; or msg = cmd + delim + finaltime + ",A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",0.0,E,S" + splat; or msg = cmd + delim + finaltime + ".000,A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",0.0,E,S" + splat;

bnevets27 commented 8 months ago

Ok, another debug so you can check that the level shift board is working also. Using the FTDI do the same test connecting it to the HV1 and GND and see if messages are ok too.

I did try that and everything was good there too. I would expect that the clock can take a 5v or 3.3v due to the manual mentioning being able to accept RS232 or TTL signals.

Meanwhile let's hope PV Electronics give us some light, but as soon I get time I will investigate a way of my code sends a GPS lock/fix message too, I just think I need some specific timings that I don't know yet.

I did get a response but it was just to ask me basic troubleshooting (how was it wired, for example). Hopefully I get some better info soon.

UPDATE: Doing a quick find I found this other code on GITHUB, you can try it also to see if it works for you. Strangely they connect the ESP8266 directly to the NIXIE clock without any level shifter so maybe depending the type of clock it can handle the serial at only 3.3V.

Nice find! I didn't find that one. I tried the code from that project, checked output via FTDI adapter and everything looks good. Tried with and without the level shifter. Clock still isn't showing any signs of communicating.

I tried the format in #https://github.com/xSnowHeadx/FakeGPS/issues/1 though I'm not sure I edited the code correctly as I couldn't just copy and past that string into the code as it gave an error about the loctime so I changed the code to this sprintf(tstr, "$GPRMC,%02d%02d%02d.00,A,0000.0000,N,00000.0000,E,00.0,0000.0,%02d%02d%02d,0.0,E,S", tmtime->tm_hour, tmtime->tm_min, tmtime->tm_sec, tmtime->tm_mday, tmtime->tm_mon, tmtime->tm_year - 2000); no idea if that was right but it did compile and send out $GPRMC sentences.

FINAL UPDATE: Looking further on the information they provided from that GITHUB pages you can also try this (either one or the other change at line 594 of my code):

I tried editing your code. Changed line 594 to the each one of the options you posted. All worked correctly but the clock didn't update/GPS LED didn't come on. Tried both with the level shifter (5v) and without (3.3v). Also tried powering the ESP via the usb or via the 5.2v from the clock to the Vin. No change.

EDIT: I got an email back from pv electronics.

Have a look in the circuit diagram in the back of the manual and you will see that the GPS input on the din connector is fed through a transistor inverter because it was designed for a br 335gps which uses an odd inverted signal format but the pic micro needs standard uart signal levels just like the ESP sends. Even though the ESP will be sending 3.3 volt signal levels this will happily register as a high for the pic micro. So you will need to bypass the transistor inverter stage to directly feed the signal into pin 18 of the pic micro. I would also remove the decimal point and redundant digits after the time and send the time in the format ,HHMMSS,

Do it looks like I need to bypass that transistor inverter and feed 3.3v directly to the pic micro.

bnevets27 commented 8 months ago

It works! ....with the code from #https://github.com/xSnowHeadx/FakeGPS

I had to remove the transistor, and remove the 5.2v going to pin 18. The ESP in now going from pin 5 (of the GPS connector) through R13 (10k resistor) to pin 18 of IC2 (PIC16F1936).

Knowing that I'm going back and testing your suggested change of line 594

EDIT: So none of the suggested changes work. But the format used in the project by xSnowHeadx does work.

Of course you never intended to support this clock so I wouldn't be an expectation it would work.

BaltasarParreira commented 8 months ago

Great news, you have it working !!! I never looked the circuit design carefully... my bad... but I expect that it was designed for a normal GPS signal operation and not a specify one that needs the inversion. : (

Anyway if it's working with that other code and you just changed the GPS string for this one that you indicate and I copy it here again: sprintf(tstr, "$GPRMC,%02d%02d%02d.00,A,0000.0000,N,00000.0000,E,00.0,0000.0,%02d%02d%02d,0.0,E,S", tmtime->tm_hour, tmtime->tm_min, tmtime->tm_sec, tmtime->tm_mday, tmtime->tm_mon, tmtime->tm_year - 2000);

I can see some differences from mine, even from the new four versions I asked you to try last time. So if you are willing to spend some more time and just for my curiosity if my code can work as well, could you test again changing the same 594 line to this one instead: msg = cmd + delim + finaltime + ".00,A," + latitude + delim + longitude +",00.0,0000.0" + delim + date + ",0.0,E,S" + splat;

If this doesn't work the problem should be related with the timings for sure, as I'm sending the GPS message every second and they looks like are sending with a bigger time interval, not sure yet how much, need to further analyze they're code.

bnevets27 commented 8 months ago

I have no problem at all trying out modifications to your code. To clarify, I didn't modify the code on that project at all, just used the format that was already there being:

sprintf(tstr, "$GPRMC,%02d%02d%02d,A,0000.0000,N,00000.0000,E,0.0,0.0,%02d%02d%02d,0.0,E,S", tmtime->tm_hour, tmtime->tm_min, tmtime->tm_sec, tmtime->tm_mday, tmtime->tm_mon + 1, tmtime->tm_year - 100);

Let me know if there is something you want me to try. Yes, they do send the GPS message much slower than you are in your code. Which may be a factor as well.

I had seen the transistor there but I didn't realize that it was inverting the logic. I'm not great with circuit diagrams. And I also didn't expect it to be designed for some odd GPS module.

BaltasarParreira commented 8 months ago

Thanks for helping with further tests. So I see. if you use they're original code without any modification my 594 line should be like this:

msg = cmd + delim + finaltime + ",A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",0.0,E,S" + splat;

But this one is the same as the third version from those four I asked you to test before, so unless the first time you did it you skipped something or was not yet after the electronic circuit modification... it should work if none of this happened... so It must be the timings and for that you need to change my code like this also: line 595 to if (timeClient.getMinutes() != lastsecond) { line 597 to lastsecond = timeClient.getMinutes();

This will make the GPS message be sent every minute as looks like they are also doing.

bnevets27 commented 8 months ago

I had actually done all of those changes twice to make sure I didn't miss anything and that was after the hardware change.

I'll give the timing changes a shot in a little bit as I'm also trying to make one other modification that I'm currently trying to figure out as well.

BaltasarParreira commented 8 months ago

Ok, thanks.

What are you trying to figure out? Something I can help?

bnevets27 commented 8 months ago

Thankfully Pete from PV Electronics helped me figure out the other modification. The modification was to turn off the tubes. I now have another esp chip that I can use to control if the tubes are on or off.

I'll get to trying your modification in a bit and get back to you. Thank you so much for the help. I wouldn't have got to this point with out your help.

It's been a dream to have my clock to finally work like this.

bnevets27 commented 6 months ago

Sorry for the delay getting back to this. I wanted to get a hold of some more esp boards to make going back and forth a bit easier.

I made the suggested edits and lines 593 to 598, are shown below. The serial monitor is still printing the GPS message every second, and the clock doesn't update the time.


String cmd = "$GPRMC";    // a command name
msg = cmd + delim + finaltime + ",A," + latitude + delim + longitude +",0.0,0.0" + delim + date + ",0.0,E,S" + splat;
if (timeClient.getMinutes() != lastsecond) {
    outputMsg(msg); // print the entire message string, and append the CRC
    lastsecond = timeClient.getMinutes();
  }
BaltasarParreira commented 6 months ago

Hi again, thanks for keep trying this so we can check if there is a final working solution.

I'm running out of ideas here for now since we changed the string "msg" to send the same as the other git code does and now the timing for just every minute as you can see for sure on the serial log passing that now the messages are less and only one per minute, right?

bnevets27 commented 6 months ago

now the timing for just every minute as you can see for sure on the serial log passing that now the messages are less and only one per minute, right?

Sorry for the confusion. No the serial log is showing a message every second still, even with the the changes you suggested.

BaltasarParreira commented 5 months ago

Hi, sorry just replying now, a lot of work lately. : ( But finally I had some time and managed to flash the test code and my serial debug is only showing a message every minute and not every second as originally.

I just changed this code as I said before here:

if (timeClient.getMinutes() != lastsecond) {
    outputMsg(msg); // print the entire message string, and append the CRC
    lastsecond = timeClient.getMinutes();
}

So are you sure that you use this same code lines on your test?