NextSync Release Thread

Show us your work, thrill and amaze us :)

Moderator: Programming Moderators

garrylancaster
Posts: 31
Joined: Mon Feb 19, 2018 2:44 pm

Re: NextSync 0.5

Postby garrylancaster » Tue May 19, 2020 11:06 am

I've had a quick go with this, but the file data doesn't seem to get transferred correctly, so the server just constantly loops on the first block responding to "Get" and "Retry" commands.

I've tried on both MacOS and Linux with the same results. Thought it might also be down to ESP firmware differences, but I also get the same on two different ESPs (one with FW v1.2.0.0 and one with FW v1.6.2.0).

User avatar
sol_hsa
Posts: 266
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: NextSync 0.5

Postby sol_hsa » Tue May 19, 2020 11:50 am

It would seem the timings are a bit too tight to be reliable. I did not expect a "it works on my machine" to happen with this one, though =)

garrylancaster
Posts: 31
Joined: Mon Feb 19, 2018 2:44 pm

Re: NextSync 0.5

Postby garrylancaster » Tue May 19, 2020 12:02 pm

Perhaps the video mode timings aren't being taken into account when setting up the UART? I normally use VGA0 but switching to HDMI gave slightly different behaviour - the 2 test files I had eventually transferred, albeit corrupted (there were still plenty of retries, but clearly the XOR checksums randomly matched at some point).

User avatar
NML32
Posts: 20
Joined: Tue May 30, 2017 9:12 am

Re: NextSync 0.5

Postby NML32 » Tue May 19, 2020 12:51 pm

Update: I am now able to connect and sync. It seems I was being too aggressive with trying to sync to many files at one time.
I was able to transfer one text file but when I tried multiple files I got the same results as Garry.

2020-05-19 08:49:40 | Sending 1024 bytes, offset 0 / 1265 checksum 96 packet size 1025
2020-05-19 08:49:40 | Data received: "Retry", 5 bytes
2020-05-19 08:49:40 | Rewinding
2020-05-19 08:49:40 | Data received: "Get", 3 bytes
2020-05-19 08:49:40 | Sending 1024 bytes, offset 0 / 1265 checksum 96 packet size 1025
2020-05-19 08:49:40 | Data received: "Retry", 5 bytes
2020-05-19 08:49:40 | Rewinding

User avatar
sol_hsa
Posts: 266
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: NextSync 0.5

Postby sol_hsa » Tue May 19, 2020 1:03 pm

garrylancaster wrote:
Tue May 19, 2020 12:02 pm
Perhaps the video mode timings aren't being taken into account when setting up the UART? I normally use VGA0 but switching to HDMI gave slightly different behaviour - the 2 test files I had eventually transferred, albeit corrupted (there were still plenty of retries, but clearly the XOR checksums randomly matched at some point).
The video timings are taken care of. I'm using basically the same code as .uart for config.
What I expect is happening is that my receive function still times out too early and part of the incoming packet is not handled and/or ends up in the next packet, which is bad. Your guess about the xor thing sounds true. The resulting file was probably also shorter than it should have been.

I'll revise the protocol so that I'm not relying on the timeout, and I'll add another layer of checksums.
NML32 wrote:
Tue May 19, 2020 12:51 pm
Update: I am now able to connect and sync. It seems I was being too aggressive with trying to sync to many files at one time.
I was able to transfer one text file but when I tried multiple files I got the same results as Garry.
The number of files at a time doesn't matter. The same problem will occur in any case.

User avatar
NML32
Posts: 20
Joined: Tue May 30, 2017 9:12 am

Re: NextSync 0.5

Postby NML32 » Tue May 19, 2020 1:11 pm

sol_hsa wrote:
Tue May 19, 2020 1:03 pm
NML32 wrote:
Tue May 19, 2020 12:51 pm
Update: I am now able to connect and sync. It seems I was being too aggressive with trying to sync to many files at one time.
I was able to transfer one text file but when I tried multiple files I got the same results as Garry.
The number of files at a time doesn't matter. The same problem will occur in any case.
Weird, when I reduced the number of files I stopped getting the "Server version mismatch" error. I have two Spectrum Next and both got the error before I reduced the number of files.

User avatar
sol_hsa
Posts: 266
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: NextSync 0.5

Postby sol_hsa » Tue May 19, 2020 1:41 pm

Here's some test versions: http://iki.fi/sol/temp/syncslow.zip
sync1k.dot - Increased receive timeout from 100 cycles to 1000 cycles.
syncs1.dot - Runs uart at standard speed
syncs2.dot - Runs uart at standard speed, does not change next cpu speed.

User avatar
sol_hsa
Posts: 266
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: NextSync 0.5

Postby sol_hsa » Tue May 19, 2020 1:41 pm

I'm still fairly certain the real fix is to change the protocol, but I won't have time to work on that before the evening..

User avatar
NML32
Posts: 20
Joined: Tue May 30, 2017 9:12 am

Re: NextSync 0.5

Postby NML32 » Tue May 19, 2020 2:05 pm

sync1k.dot didn't work
syncs1.dot worked
syncs2.dot worked

I tested with .txt and .ini files. No corruption.
Edit: I added file BUBNEXTB4.nex worked fine. No corruption.

User avatar
sol_hsa
Posts: 266
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: NextSync 0.5

Postby sol_hsa » Tue May 19, 2020 2:48 pm

That's interesting. I expected all of them to work, but made several just in case.

Code: Select all

pc --a-> network --b-> wifi module --c-> uart --d-> next
There's several asyncronous things going on.
I believe everything goes fine in 'a' and 'b'.
'c' can go wrong if the baud rate is so high that the uart's buffer overflows. I doubt this is the case though because we're very aggressively reading from it.
'd' can go wrong if we believe the transmission is over and start looking at the packet even though it's not complete yet.

Both 'c' and 'd' can of course go wrong if the prescalers are wrong and data just gets corrupted.

I thought increasing the timeout value by 10x would be enough to make sure 'd' works, but apparently that wasn't the case. In fact, dropping the baud rate should let 'd' timeout even faster. On the other hand high baud rate might cause 'c' to overflow, if we're not reading it fast enough. Again, I really doubt that's the case.

It's possible that the tcp packet is split and/or resent several times and we run out of time when receiving. Maybe I'm running in too ideal conditions and haven't hit this.

By adding the packet size to the start of each packet I can pretty much get rid of the timeout in 'd' and wait for however long it takes for the packet to get transmitted, so that should make everything more robust.


Who is online

Users browsing this forum: PowerfulBadBoy and 1 guest