fujinet #FujiNet - a WIP SIO Network Adapter for the Atari 8-bit

[tschak909]

Those pings are _terrible_, wow.

 

For comparison, pinging my fujinet:

 

PING thom.home (192.168.1.11) 56(84) bytes of data.
64 bytes from thom.home (192.168.1.11): icmp_seq=1 ttl=255 time=120 ms
64 bytes from thom.home (192.168.1.11): icmp_seq=2 ttl=255 time=14.9 ms
64 bytes from thom.home (192.168.1.11): icmp_seq=3 ttl=255 time=37.6 ms
64 bytes from thom.home (192.168.1.11): icmp_seq=4 ttl=255 time=59.0 ms
64 bytes from thom.home (192.168.1.11): icmp_seq=5 ttl=255 time=84.0 ms
64 bytes from thom.home (192.168.1.11): icmp_seq=6 ttl=255 time=107 ms
^C
--- thom.home ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 14.891/70.332/119.665/37.015 ms

 

[FifthPlayer]

7 hours ago, tschak909 said:

I have added a note to the Quick Start Guide:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Quickstart-Guide

 

If you need to persist disk slots between cold starts, please power your #FujiNet externally. 

 

-Thom

Mine was persisting disk slots even before powering it externally.  I assume this is because it has an SD card inserted?

[tschak909]

I need to be more specific, by persist, I mean, keep mounted. When the #FujiNet is cold started, nothing is actually mounted except the CONFIG ROM disk itself, and CONFIG has to mount the servers and disks in the device slots (this is what happens when you press OPTION). If you keep the unit powered, this persists across reboots, and you don't see CONFIG again until you reset the #FujiNet.

 

-Thom

 

[MrFSL]

  

2 hours ago, FifthPlayer said:

Thank you for the continuous ping suggestion.  Here are some ping statistics I'm getting for my Fujinet.  It seems like 300ms latency might be close to "normal"

I have 2 Atari computers. One has a modification that might be causing some interference - the other is just completely stock. The latency of my Fujinet is average 300ms regardless of which Atari I use or how close it is to the wifi router. I can literally take my Atari to the barn away from everything else electronic and connect it to wireless hotspot and the ping averages 300ms.

 

2 hours ago, tschak909 said:

Those pings are _terrible_, wow.

I'm not sure what else I could do about it. I have a friend who works in RF looking into it for me --- but he isn't exactly very interested in Atari so I am not sure how far he will delve. --- I would be curious which of us is in the minority here. As I said in another thread - my unit seems exceptionally prone to interference. I should also ask what wireless channel (and country) folks are running their wifi. I was asked to change to channel 11 (US) and see if it makes a difference but I haven't gotten around to it yet.

 

1 hour ago, FifthPlayer said:

powering it externally.

When I mentioned powering mine externally I meant FOR TESTING PING RATES I wasn't at all connected to an Atari, rather I was powering it externally. I did this to (1) make it more portable and (2) to cut out any variables induced by the Atari. I'm literally walking around with a battery powered Fujinet with my inline USB power meter and no computer attached when running running ping tests.

 

 

 

[MrFSL]

1 hour ago, MrFSL said:

I should also ask what wireless channel (and country) folks are running their wifi. I was asked to change to channel 11 (US) and see if it makes a difference but I haven't gotten around to it yet.

 

It makes absolutely no difference. 

[Jochen]

Hi,
i am following this thread with interest because i keep having problems with the connection to the TNFS servers on the internet. I once did a ping long-term measurement and it was disastrous! time outs again and again. I had the same thing even if I only connected the Fujinet to power, then it still works and connects to the router. with that I could exclude the atari. I have no idea how, I had the idea to experiment with the WLAN channels on the router. From auto to channel 11 and there was a constant connection for over 1.5 hours and I was able to easily reach every server and mount images. After a few hours the atari switched on again, test and again time outs. The channel from 11 to 6 and it was working without any time outs. I have no idea how my iphone is involved, I always connected it to 5Ghz.

Maybe it will help someone

JOchen

 

•  

[+x=usr(1536)]

Does the Fujinet support both 2.4GHz and 5GHz networks?

 

This looks like something I've seen before with other devices, but want to check that before I start leaping into theories.

[leech]

30 minutes ago, x=usr(1536) said:

Does the Fujinet support both 2.4GHz and 5GHz networks?

 

This looks like something I've seen before with other devices, but want to check that before I start leaping into theories.

Sadly it only supports 2.4ghz.

[+x=usr(1536)]

6 minutes ago, leech said:

Sadly it only supports 2.4ghz.

 

Understood, but that's actually a good thing in this case - it eliminates the possibility of an issue with trying to connect to SSIDs with the same name on both 2.4 and 5GHz on the same AP.  Some clients *really* don't like doing that.

 

Anyway, that shoots my theory down.

Edited December 22, 2020 by x=usr(1536)

[manterola]

When my Fujinet starts to get too funky, in my case it helps to power cycle my 2.4GHz/5GHz access point (with different SSIDs). I can notice the difference immediately, even when my other devices don't have problems with the same access point (it is really a router not doing routing). I don't know what it is, maybe Fujinet overflowing some router internal table, but I am seriously considering getting an good old router or access point (maybe 802.11b only, or b/g) to use with exclusively with Fujinet and see.

 

 

Edited December 22, 2020 by manterola

[FifthPlayer]

11 hours ago, MrFSL said:

  

When I mentioned powering mine externally I meant FOR TESTING PING RATES I wasn't at all connected to an Atari, rather I was powering it externally. I did this to (1) make it more portable and (2) to cut out any variables induced by the Atari.

 

 

Here's a ping I just ran with Fujinet active but the Atari switched off.  Same result as before.

 

Pinging 192.168.1.33 with 32 bytes of data:
Reply from 192.168.1.33: bytes=32 time=573ms TTL=255
Reply from 192.168.1.33: bytes=32 time=383ms TTL=255
Reply from 192.168.1.33: bytes=32 time=213ms TTL=255
Reply from 192.168.1.33: bytes=32 time=434ms TTL=255
Reply from 192.168.1.33: bytes=32 time=231ms TTL=255
Reply from 192.168.1.33: bytes=32 time=22ms TTL=255
Reply from 192.168.1.33: bytes=32 time=266ms TTL=255

Ping statistics for 192.168.1.33:
Packets: Sent = 7, Received = 7, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 573ms, Average = 303ms

The environment is a home office with several other devices, including the router, within the same 15x15 foot room.  However there is a Raspberry Pi with Wifi less than a meter away from the Fujinet.  I powered the RPi down and re-ran the ping test (again, with Atari off).  Pretty much the same result.

 

Pinging 192.168.1.33 with 32 bytes of data:
Reply from 192.168.1.33: bytes=32 time=457ms TTL=255
Reply from 192.168.1.33: bytes=32 time=253ms TTL=255
Reply from 192.168.1.33: bytes=32 time=58ms TTL=255
Reply from 192.168.1.33: bytes=32 time=277ms TTL=255
Reply from 192.168.1.33: bytes=32 time=91ms TTL=255
Reply from 192.168.1.33: bytes=32 time=314ms TTL=255
Reply from 192.168.1.33: bytes=32 time=120ms TTL=255
Reply from 192.168.1.33: bytes=32 time=328ms TTL=255
Reply from 192.168.1.33: bytes=32 time=137ms TTL=255
Reply from 192.168.1.33: bytes=32 time=352ms TTL=255
Reply from 192.168.1.33: bytes=32 time=159ms TTL=255

Ping statistics for 192.168.1.33:
Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 58ms, Maximum = 457ms, Average = 231ms

 

I am using a Synology RT 2600ac router.

Edited December 22, 2020 by FifthPlayer
Adding access point info

[tschak909]

I am using a Ubiquiti access point, here at the house.

 

-Thom

 

[MrFSL]

39 minutes ago, FifthPlayer said:

The environment is a home office with several other devices, including the router, within the same 15x15 foot room.  However there is a Raspberry Pi with Wifi less than a meter away from the Fujinet.  I powered the RPi down and re-ran the ping test (again, with Atari off).  Pretty much the same result.

Yeah. At this point your results are showing consistent with my own. At this point I am out of ideas unless Thom or someone could provide an application that shows us what the device sees. Perhaps wireless signal/noise in the configuration web page or in an Atari app. 

 

  

2 hours ago, manterola said:

I don't know what it is, maybe Fujinet overflowing some router internal table, but I am seriously considering getting an good old router or access point (maybe 802.11b only, or b/g) to use with exclusively with Fujinet and see.

Cool. Let me know if it works any better for you. I have tried a number including mobile hot spots and different vendors with no luck. 

 

 

I considered this might have to do with the lack of space around the antenna; but then I would think it would effect mostly everyone.

 

 

Edited December 22, 2020 by MrFSL

[MrFSL]

5 hours ago, manterola said:

I don't know what it is, maybe Fujinet overflowing some router internal table

I decided to build my own AP so I could intercept the traffic as close as I could to the WAP. I also disabled all security just in case. The tcpdump was uneventful. Nothing is happening here that shouldn't be happening. ARP events, UDP events for NTP,  DNS events. Nothing sticks out. The ping rates to this new access point are the same as they have been.

 

I used a couple different external wireless adapters on a laptop to measure link qualities. I placed this directly adjacent to the fujinet and they are detecting no noise.

 

At this point it seems apparent that this is just how my Fujinet functions. I purchased it pre-built so the question becomes, is the way in which it is functioning within spec or not? (The user experience is not good.)

 

My device is extremely susceptible to "noise" or interference which does not effect other wifi devices and is not detectable by other network adapters. In general this would point me towards antenna problems. The antenna appears visually to have no noticeable issues (to my untrained eyes.)

 

Bluetooth connectivity is hit or miss as well and I understand it uses the same antenna. Anyone else experiencing issues with bluetooth reliability using the device as a sio2bt adapter?

 

With a bunch of work I can get it "working" although extremely latent. With confirmation from the Fujinet gods I would accept that this is how the device functions - I bought a v1.0 of the hardware and therefore you get what you get. If however ya'll think that a handful of us have received devices functioning outside of desired spec - perhaps we can work with the vendor on repairs/replacements/etc.

 

I appreciate everyone's take on this.

 

 

 

[tschak909]

Status Report: I am grinding through the HTTP protocol adapter in the N: rewrite.

 

Sometimes, the thing you hope to do doesn't quite land.

 

To explain, 

 

HTTP is a complex protocol. You have multiple verbs, GET (read), PUT (write), POST (write, then read) are the three main verbs. There are also specialty verbs, PROPFIND (get directory), MKCOL (make directory), COPY (copy a file), DELETE (delete a file), RMCOL (remove a directory), HEAD (get headers only), and others.

 

I have mapped these to the following CIO AUX1 values:

4, 12 = GET
8     = PUT
13    = POST

Notice there are two values for GET. There's a reason for this: Most programs that open a file for reading expect to use AUX1=4, and they expect a file. You can not write to a channel opened with this mode. Because the only way to send something back to the fujinet is via a write, it means that you can't send headers with this mode, and thus you need mode 12 (both read and write direction bits set), to be able to pull this off, so there are two modes for GET, 4 = just get the file, 12 = you can write headers before you actually get the response.

 

So the way I _WANTED_ this to work was like this:

 

0 DIM A$(99)
10 OPEN #1,12,2,"N:HTTP://FUJINET-TESTING.IRATA.ONLINE/"
20 XIO 77,#1,12,1:REM SWITCH TO HEADERS MODE
30 PRINT #1;"Date":REM I want the Date header
31 PRINT #1;"ETag":REM I want the ETag header
32 REM THE NEXT INPUT WILL START THE HTTP TRANSACTION,
33 REM AND SINCE WE ARE IN HEADER MODE, THE NEXT INPUT
34 REM WILL GRAB THE Date HEADER.
40 INPUT #1,A$:? "Date: ";A$
50 INPUT #1,A$:? "ETag: ";A$
60 XIO 77,#1,12,0:REM SWITCH TO BODY MODE
70 TRAP 100
80 PRINT "BODY: ":PRINT
90 INPUT #1,A$
100 CLOSE #1:END

 

We have an XIO that sets whether to set the channel to BODY or HEADERS mode. We switch between them to to change the behavior of the I/O channel. Sounds simple and elegant, right? sigh. ?

 

The #FujiNet's N: device is interrupt driven. This is absolutely critical, because EVERYTHING happens on the #FujiNet, with the N: handler being a pass-through, meaning that every open, every close, every read, every write; even every status request results in an SIO transaction on the bus, which, if you're not turning off the beeps via clearing SOUNDR, it can get awfully noisy. We solve this problem by asserting the PROCEED line when there are either bytes waiting, or the connection state of a protocol somehow changes. Otherwise, the N: handler will sit there waiting patiently for something to happen...

 

In Data mode, we set the size to -1, and use this to indicate that when we start the HTTP transaction, we get the Content-Length: and use that to set the # of bytes waiting to retrieve. Since this length is > 0, this causes the interrupt line to assert itself, and allows the READ to retrieve the # of requested bytes from the buffer (<= number of bytes available).

 

In Headers mode, we are writing to the channel, and then we switch to read, which returns the data length of the returned headers.

 

The status command is done to get the length of the returned headers, then the read ha... Oh shit! a race condition. The HTTP transaction hasn't happened yet, there is no way to actually determine if we are actually DONE with writing, because the status happens BEFORE the read. 

 

So this leads me to one of at least two possible solutions:

 

(1) Have yet another XIO that actually does the transaction. 

 

(2) Have a variable that is temporarily on for ONE write, to accept a comma delimited set of header keys to receive (127 bytes max).

 

Both are small speed-bumps, but does anyone have an issue with this? I've been hacking on this for a few days straight, and am getting really burnt out.

 

-Thom

 

[tschak909]

1 hour ago, MrFSL said:

I decided to build my own AP so I could intercept the traffic as close as I could to the WAP. I also disabled all security just in case. The tcpdump was uneventful. Nothing is happening here that shouldn't be happening. ARP events, UDP events for NTP,  DNS events. Nothing sticks out. The ping rates to this new access point are the same as they have been.

 

I used a couple different external wireless adapters on a laptop to measure link qualities. I placed this directly adjacent to the fujinet and they are detecting no noise.

 

At this point it seems apparent that this is just how my Fujinet functions. I purchased it pre-built so the question becomes, is the way in which it is functioning within spec or not? (The user experience is not good.)

 

My device is extremely susceptible to "noise" or interference which does not effect other wifi devices and is not detectable by other network adapters. In general this would point me towards antenna problems. The antenna appears visually to have no noticeable issues (to my untrained eyes.)

 

Bluetooth connectivity is hit or miss as well and I understand it uses the same antenna. Anyone else experiencing issues with bluetooth reliability using the device as a sio2bt adapter?

 

With a bunch of work I can get it "working" although extremely latent. With confirmation from the Fujinet gods I would accept that this is how the device functions - I bought a v1.0 of the hardware and therefore you get what you get. If however ya'll think that a handful of us have received devices functioning outside of desired spec - perhaps we can work with the vendor on repairs/replacements/etc.

 

I appreciate everyone's take on this.

 

 

 

You can always contact the vendor to see if they can swap a unit with you, to see if it is indeed the unit. I am honestly very surprised by your ping responses. 

-Thom

[Mr Robot]

OK so I pinged my fujinets for a bit. I have three, all beta versions, hardware rev 1.0, 1.1 and 1.3.

Here are my results

Spoiler

PING fujixel.home.lan (192.168.2.31): 56 data bytes
64 bytes from 192.168.2.31: icmp_seq=0 ttl=255 time=518.111 ms
64 bytes from 192.168.2.31: icmp_seq=1 ttl=255 time=133.484 ms
64 bytes from 192.168.2.31: icmp_seq=2 ttl=255 time=48.605 ms
64 bytes from 192.168.2.31: icmp_seq=3 ttl=255 time=541.828 ms
64 bytes from 192.168.2.31: icmp_seq=4 ttl=255 time=191.981 ms
64 bytes from 192.168.2.31: icmp_seq=5 ttl=255 time=111.609 ms
64 bytes from 192.168.2.31: icmp_seq=6 ttl=255 time=31.877 ms
64 bytes from 192.168.2.31: icmp_seq=7 ttl=255 time=536.049 ms
64 bytes from 192.168.2.31: icmp_seq=8 ttl=255 time=174.593 ms

PING fujixl.home.lan (192.168.2.30): 56 data bytes
64 bytes from 192.168.2.30: icmp_seq=0 ttl=255 time=490.424 ms
64 bytes from 192.168.2.30: icmp_seq=1 ttl=255 time=101.211 ms
64 bytes from 192.168.2.30: icmp_seq=2 ttl=255 time=16.566 ms
64 bytes from 192.168.2.30: icmp_seq=3 ttl=255 time=510.802 ms
64 bytes from 192.168.2.30: icmp_seq=4 ttl=255 time=161.296 ms
64 bytes from 192.168.2.30: icmp_seq=5 ttl=255 time=80.147 ms
64 bytes from 192.168.2.30: icmp_seq=6 ttl=255 time=575.045 ms
64 bytes from 192.168.2.30: icmp_seq=7 ttl=255 time=491.575 ms
64 bytes from 192.168.2.30: icmp_seq=8 ttl=255 time=144.755 ms

PING fujinuc.home.lan (192.168.2.32): 56 data bytes
64 bytes from 192.168.2.32: icmp_seq=0 ttl=255 time=344.817 ms
64 bytes from 192.168.2.32: icmp_seq=1 ttl=255 time=531.230 ms
64 bytes from 192.168.2.32: icmp_seq=2 ttl=255 time=178.982 ms
64 bytes from 192.168.2.32: icmp_seq=3 ttl=255 time=97.988 ms
64 bytes from 192.168.2.32: icmp_seq=4 ttl=255 time=15.894 ms
64 bytes from 192.168.2.32: icmp_seq=5 ttl=255 time=507.535 ms
64 bytes from 192.168.2.32: icmp_seq=6 ttl=255 time=155.639 ms
64 bytes from 192.168.2.32: icmp_seq=7 ttl=255 time=72.450 ms
64 bytes from 192.168.2.32: icmp_seq=8 ttl=255 time=566.517 ms

 

All broadly the same, all very variable, all a bit crap. 

 

Everything else on the LAN that I tested came back with ~3-6ms pings except for an old Mac Mini and an old Macbook Pro that looked similar to the Fujinets. It should be noted that the poor pings are all coming from the devices on my 2.4ghz network, the good pings are all on a 5ghz network. Switching over to the 2.4 ghz network before running the ping test to take bridging out of the equation didn't make any noticeable difference.

 

 

[toddtmw]

This site compares 2.4 and 5 pings and shows that 2.4 is much less consistent. there’s even a graph that shows it in detail. 
 

https://blog.parsec.app/how-your-wifi-band-impacts-low-latency-connections-9f1e538a63dd/

[Mr Robot]

Thanks, that matches what I see almost perfectly and the ESP not supporting 5 networks is just something we have to live with.

 

So why is is so obvious something is awry here when we've been collectively ignoring it for years? I expect the answer is that most wifi devices have pretty robust error correction in firmware, resending stuff that is OOB and generally making the network look like it's running smoothly. The ESP32 wifi stack seems to be pretty bare bones in that regard.

 

[tschak909]

6 minutes ago, Mr Robot said:

Thanks, that matches what I see almost perfectly and the ESP not supporting 5 networks is just something we have to live with.

 

So why is is so obvious something is awry here when we've been collectively ignoring it for years? I expect the answer is that most wifi devices have pretty robust error correction in firmware, resending stuff that is OOB and generally making the network look like it's running smoothly. The ESP32 wifi stack seems to be pretty bare bones in that regard.

 

so we basically need to make that better somehow... ?

 

-Thom

[FifthPlayer]

2 hours ago, tschak909 said:

So this leads me to one of at least two possible solutions:

 

(1) Have yet another XIO that actually does the transaction. 

 

(2) Have a variable that is temporarily on for ONE write, to accept a comma delimited set of header keys to receive (127 bytes max).

 

 

I have to admit, I read your description a few times and I still don't have a clear picture in my head of what the problem is. I think partly because it's not entirely clear to me what's happening in the N: handler and what's happening on the ESP32.  A sequence diagram would clear up things a great deal but for me the question I would want to ask is: what does the end-programmer's BASIC code look like for both of these solutions?  Is the BASIC code unchanged in either/both these solutions?  For option #1 I'm guessing no since you're proposing another XIO call.  

 

In terms of which solution I'd prefer, two XIO calls that are straightforward to code and straightforward to understand are usually better than a "special case" variable in the code (which I'm guessing happens totally on the ESP32 side?).  Special cases in software design are usually an invitation for unintentional problems down the line.

 

Edited December 22, 2020 by FifthPlayer

[MrFSL]

58 minutes ago, tschak909 said:

You can always contact the vendor to see if they can swap a unit with you, to see if it is indeed the unit. I am honestly very surprised by your ping responses. 

Thanks Thom. I might. --- There is a big part of me that hesitates from asking anything from the vendor. There was much documentation on Fujinet that explained it was still under a great amount of hardware/software development when I purchased it. Shouldn't I expect that not all the bugs are ironed out when purchasing under those conditions?

 

I will notify them for sure just in case there is a systemic issue with a part vendor or something like that; and I will @MacRorie and @Gavin1968 both here to draw their attention as well.

 

My goal, and the actual important take away here is that moving forward the community knows what "right looks like." Is the latency and susceptibility to interference typical or atypical? I'm starting to see that it is more atypical, perhaps a bad batch of components. But, we should make sure that some steps be added to the QC and testing process as this is something that appears to be measurable and consistently repeatable and I don't seem to be the only person with this issue.

 

Really enjoy playing around here. And, lets be honest, If everything worked perfectly this would be a lot less fun for me.

 

 

[Mr Robot]

The next batch of ESP's I order will be the new part with the external antenna port, I shall get an antenna ad see if it improves things. 

 

Given the page @toddtmw linked it looks like the signal is what the signal is and it's going to be down to software to make that not noticable.

[mozzwald]

Here are my results from a v1.0 and v1.3. My router is on the 2nd floor and I also tested with the fujinets downstairs on the main floor. The v1.0 has a WROVER-B, v1.3 has a WROVER-IE (jumpered for PCB antenna). FWIW, my router is a POS Netgear WNDR3400 running DD-WRT configured with different SSID names for 2.4g and 5g. There were reports of having the same SSID name for 2.4/5g causing problems (I've always had my names different so I cannot confirm).

Spoiler

--------------- v1.3 next to router -----------------
PING  (192.168.1.113) 56(84) bytes of data.
64 bytes from  (192.168.1.113): icmp_seq=1 ttl=255 time=33.9 ms
64 bytes from  (192.168.1.113): icmp_seq=2 ttl=255 time=60.3 ms
64 bytes from  (192.168.1.113): icmp_seq=3 ttl=255 time=76.4 ms
64 bytes from  (192.168.1.113): icmp_seq=4 ttl=255 time=124 ms
64 bytes from  (192.168.1.113): icmp_seq=5 ttl=255 time=19.2 ms
64 bytes from  (192.168.1.113): icmp_seq=6 ttl=255 time=41.6 ms
64 bytes from  (192.168.1.113): icmp_seq=7 ttl=255 time=64.5 ms
64 bytes from  (192.168.1.113): icmp_seq=8 ttl=255 time=86.2 ms
64 bytes from  (192.168.1.113): icmp_seq=9 ttl=255 time=6.41 ms
64 bytes from  (192.168.1.113): icmp_seq=10 ttl=255 time=29.0 ms

---  ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 6.413/54.225/124.273/33.587 ms

 

--------------- v1.3 first floor -----------------
PING  (192.168.1.113) 56(84) bytes of data.
64 bytes from  (192.168.1.113): icmp_seq=1 ttl=255 time=409 ms
64 bytes from  (192.168.1.113): icmp_seq=2 ttl=255 time=25.1 ms
64 bytes from  (192.168.1.113): icmp_seq=3 ttl=255 time=47.7 ms
64 bytes from  (192.168.1.113): icmp_seq=4 ttl=255 time=70.9 ms
64 bytes from  (192.168.1.113): icmp_seq=5 ttl=255 time=94.9 ms
64 bytes from  (192.168.1.113): icmp_seq=6 ttl=255 time=21.5 ms
64 bytes from  (192.168.1.113): icmp_seq=7 ttl=255 time=38.7 ms
64 bytes from  (192.168.1.113): icmp_seq=8 ttl=255 time=62.3 ms
64 bytes from  (192.168.1.113): icmp_seq=9 ttl=255 time=84.4 ms
64 bytes from  (192.168.1.113): icmp_seq=10 ttl=255 time=200 ms

---  ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9007ms
rtt min/avg/max/mdev = 21.596/105.560/409.012/112.294 ms

 

--------------- v1.0 next to router -----------------
PING  (192.168.1.121) 56(84) bytes of data.
64 bytes from  (192.168.1.121): icmp_seq=1 ttl=255 time=376 ms
64 bytes from  (192.168.1.121): icmp_seq=2 ttl=255 time=100 ms
64 bytes from  (192.168.1.121): icmp_seq=3 ttl=255 time=17.8 ms
64 bytes from  (192.168.1.121): icmp_seq=4 ttl=255 time=40.3 ms
64 bytes from  (192.168.1.121): icmp_seq=5 ttl=255 time=62.3 ms
64 bytes from  (192.168.1.121): icmp_seq=6 ttl=255 time=85.5 ms
64 bytes from  (192.168.1.121): icmp_seq=7 ttl=255 time=206 ms
64 bytes from  (192.168.1.121): icmp_seq=8 ttl=255 time=27.0 ms
64 bytes from  (192.168.1.121): icmp_seq=9 ttl=255 time=49.8 ms
64 bytes from  (192.168.1.121): icmp_seq=10 ttl=255 time=72.3 ms

---  ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 17.828/103.965/376.935/104.162 ms

 

--------------- v1.0 first floor -----------------
PING  (192.168.1.121) 56(84) bytes of data.
64 bytes from  (192.168.1.121): icmp_seq=1 ttl=255 time=36.9 ms
64 bytes from  (192.168.1.121): icmp_seq=2 ttl=255 time=74.8 ms
64 bytes from  (192.168.1.121): icmp_seq=3 ttl=255 time=104 ms
64 bytes from  (192.168.1.121): icmp_seq=4 ttl=255 time=204 ms
64 bytes from  (192.168.1.121): icmp_seq=5 ttl=255 time=20.3 ms
64 bytes from  (192.168.1.121): icmp_seq=6 ttl=255 time=43.5 ms
64 bytes from  (192.168.1.121): icmp_seq=7 ttl=255 time=77.6 ms
64 bytes from  (192.168.1.121): icmp_seq=8 ttl=255 time=89.4 ms
64 bytes from  (192.168.1.121): icmp_seq=9 ttl=255 time=112 ms
64 bytes from  (192.168.1.121): icmp_seq=10 ttl=255 time=30.7 ms

---  ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 20.327/79.476/204.854/51.486 ms
 

 

1 hour ago, Mr Robot said:

The next batch of ESP's I order will be the new part with the external antenna port, I shall get an antenna ad see if it improves things.

If I get some time I will try this also.

 

2 hours ago, MrFSL said:

There is a big part of me that hesitates from asking anything from the vendor. <SNIP> I'm starting to see that it is more atypical, perhaps a bad batch of components. But, we should make sure that some steps be added to the QC and testing process as this is something that appears to be measurable and consistently repeatable and I don't seem to be the only person with this issue.

This being an atypical issue leads me to think there could be something wrong with the board, whether it be a bad component or soldering issue. I would hope your vendor is willing to at least do a swap and see if it clears up the problem, and triple check the replacement unit before shipping

 

 

[Mr Robot]

10 minutes ago, mozzwald said:

configured with different SSID names for 2.4g and 5g. There were reports of having the same SSID name for 2.4/5g causing problems

Same here, Mine were all the same originally but I reconfigured because of people having issues with Fujinet.

 

All my kit is just mixed with other kit, lots of electronics all sharing a space, I'm expecting some level of noise. Your pings look pretty good, mine look to be about half as good as yours generally; are you taking care where your Fujinets are placed WRT other unshielded electronics?