Closed zomgugoff closed 1 month ago
Not at all mate. Glad that you are pushing and trying it all out.
You may suspect, but I have never tested that specific timezone (or any US timezone). have you tried any others? Unless you have already, perhaps try my TZ (Australia/Melbourne).
And have you tried other esp8266 communication operations (eg: setting wifi creds)? I am wondering if this is just a TZ issue, or a general communication failure.
I would expect the 'US/Pacific' time zone to work. Perhaps a regression in the application has crept in that I have not noticed. I did do some 'driver' rework a few months ago - mostly for USB stuff - i may have stuffed something up for SIO/2.
There are a few 'bits' here that all have to work. the SIO/2 driver. the ESP8266.COM application, and the actual ESP8266 - and of course the baud-rate/serial comms needs to be working reliably.
One other application to try, is the TERM.COM app. - this allows a simple
terminal to operate - if you can get it 'connected' you should be able to
type AT
If you can get that to work, its possible then to manually send the commands to the ESP8266.
Not quite in a position at the moment to try and test this myself for you today - perhaps the weekend.
I am afraid a lot of the software apps I wrote are under-documented, and tend to at best, barely work. Not much in the way of good error handling, or feedback etc. Sorry!
Cheers Dean. ]
On Thu, 15 Aug 2024 at 15:28, zomgugoff @.***> wrote:
I bet you're getting sick of me.
Trying to set the timezone with
esp8266.com set-timezone US/Pacific
Per the linked TZ wiki entry is resulting with
Error setting timezone: ERROR: Failed to set timezone.
I have tried several current US timezone codes but none are recognized. Are the values in the code out of date or missing?
— Reply to this email directly, view it on GitHub https://github.com/vipoo/yellow-msx-series-for-rc2014/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADIL7R7IXX44YRXSHA6T4TZRQ4ANAVCNFSM6AAAAABMRTCUSSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ3DONBTG43DOMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I have actually been using term.com quite a bit today. Hopped on a couple MSX BBSs (after I figured out I had to set the baud up to 115200 or the program would freeze when it got flooded with data, despite RTS/CTS and the jumper wire) and I was able to set the time zone to both your example and UTC. The other commands for esp8266.com worked without a hitch.
Interesting side note to term.com: at 115200, there is no input echo (not local echo, the normal echo). I wondered if that had something to do with the RTS line not being connected to the ESP8266. The official RC2014 dual SIO module does not have a trace connecting port B RTS from the chip to the pin header. I jumped it with a resistor and it was working flawlessly using qterm on RomWBW and Zimodem firmware. But I don't think you have a GPIO pin set to receive that in your firmware.
So it working now ok?
I am a little confused about your hardware flow control issue.
The official RC2014 dual SIO module does not have a trace connecting port B RTS from the chip to the pin header
Are you sure? I didnt have to do any modification to my SIO/2 module. The schematic seems to indicate RTSB is connected? (https://8b8bf43264c2f150841a.b-cdn.net/wp-content/uploads/2017/06/SIO2.pdf)
Its been a while since I looked at the esp8266 firmware - so I may have got this completly wrong - but from recall and having a quick look at the code it:
Serial.begin(19200);
(Have you manually changed this and compiled?)setCTSFlowControlOn()
I recall having to work a bit to make sure hardware flow control works - otherwise, yes, its not reliable.
Oops, I was referring to CTS. Neither pin header has CTS connected to them. I rigged pin 6 on the B header for CTS.
I've been using term.com /b115200
to increase the speed and aleviate the buffer issue. The echo issue I mentioned appears to have stopped. I may have had a bad session from re-running term several times without rebooting. But, the problem with term.com crashing at 19200 when a BBS sends a large amount of characters(like the connection ANSI) is still happening. The /b option is fixing that.
Oh, were you were asking if the time zone part was working? That part is still not working correctly for US time zones. Everything else seems to be fine, though.
OK. So yep, don't have the CTS support. Never expected the Z80 could deliver content faster than the connected service could support. I would though, then expect a faster baud-rate would make it worse for transmission.
In regards to the Timezone error:
The ESP8266 firmware uses the ezTime
library to manage timezones.
https://github.com/ropg/ezTime
This is the library that references https://en.wikipedia.org/wiki/List_of_tz_database_time_zones as its list of supported TZ.
I found that it doesn't support US/Pacific
- but it does support its alternative America/Los_Angeles
the zone string you submit, it sent on to a remote service - you can access that remote services using the linux command
nc
Enter this command
nc -u timezoned.rop.nl 2342
CTRL+c to exit.
I see. I didn't expect to have to use the city-based zone identifiers. It does indeed work. Thanks for clarifying.
I bet you're getting sick of me.
Trying to set the timezone with
esp8266.com set-timezone US/Pacific
Per the linked TZ wiki entry is resulting with
Error setting timezone: ERROR: Failed to set timezone.
I have tried several current US timezone codes but none are recognized. Are the values in the code out of date or missing?