Jump to content
tschak909

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

Recommended Posts

7 minutes ago, Mr Robot said:

are you taking care where your Fujinets are placed WRT other unshielded electronics?

um, no. I'd show you a picture of my desk but it's embarassing :D The 800XL sits almost under my laptop just below my monitor with big ugly surge protector next to laptop power brick, usb hub, router above the laptop, mess, 1050 on the other side of the laptop, cables, mess and more mess :P 

Share this post


Link to post
Share on other sites
On 12/21/2020 at 6:29 PM, tschak909 said:

pinging my fujinet:

Here is what I am getting out of mine, that is out in the garage at the furthest point to my access points:

I have had WiFi issues, but I attribute it to a tiny antenna, and a great distance to my access point, and a whole bunch of electronics near my FujiNet.  I have also had my FujiNet rescan for SSID's and reconnect when I notice it getting a little spotty and that seems to help.  I don't expect a great deal out of it considering the size of the antenna, the distance to the AP, the amount of devices I have in the area that are also in the WiFi and the devices causing interference.  These are radios, they are going to drop, period. I haven't ready this thread completely but I do know radios will always be less than 100% no matter what we do. Now let me go catch up :) Also, I am using 2.4GHz for my connection, and I am using a Nighthawk MR60 Mesh with one additional satellite that is about 20' from the garage where the FN is. 

 
 

Screen Shot 2020-12-22 at 6.58.15 PM.png

Edited by Gavin1968

Share this post


Link to post
Share on other sites

I'm still waiting for my Fuji to show up but I'd like to highlight one thing I haven't seen anyone mention on this thread:  802.11b/g compatibility.  Unless the Fujinet requires B/G support, turn it OFF on your home wifi AP and only enable  802.11N support.  Your network will perform significantly better for it.  It's also been mentioned a few times but for 2.4Ghz users, install a Wifi spectrum app on your phone such as Wifi Analyzer for Android by Kevin Yuan.  This can help you possibly find a better free frequency than where your AP is today.  While it's generally understood that 1, 6, and 11 are the three free frequencies, sometimes you'll get better performance using a split frequency like channel 3, or 8.

 

--David

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, Atari_bbs_fan said:

This can help you possibly find a better free frequency than where your AP is today.  While it's generally understood that 1, 6, and 11 are the three free frequencies, sometimes you'll get better performance using a split frequency like channel 3, or 8.

Great advice!! I know when I was setting up my last Nighthawk I did find a channel that was much better that was not the default channel.  Great word of advice and yes being able to analyze the RF In the area is critical! 

 

Share this post


Link to post
Share on other sites
19 minutes ago, Atari_bbs_fan said:

While it's generally understood that 1, 6, and 11 are the three free frequencies, sometimes you'll get better performance using a split frequency like channel 3, or 8.

Well - they are the three non-overlapping channels. If you are in a crowded area though where all channels are chewed up, take what you can get for sure.

 

20 minutes ago, Atari_bbs_fan said:

install a Wifi spectrum app on your phone such as Wifi Analyzer

Good suggestion, and if you are using an Android phone google on how to disable Wi-Fi scan throttling or else programs like this won't update very well.

 

image.png.4e8536119c2a0b2cbb4af540093dc3ee.png

 

 

Share this post


Link to post
Share on other sites
2 hours ago, mozzwald said:

um, no. I'd show you a picture of my desk but it's embarassing :D The 800XL sits almost under my laptop just below my monitor with big ugly surge protector next to laptop power brick, usb hub, router above the laptop, mess, 1050 on the other side of the laptop, cables, mess and more mess :P 

Sh!t Mozz! You in there? Mozz!? Can you hear me? Send up a flare if you are ok. 

 

It's alright, he's good. LOL!

 

 

  • Haha 1

Share this post


Link to post
Share on other sites

#Atari8bit Bill Kendrick added a new panel to the #FujiNet web admin, showing the current drive and host slots! Thanks, Bill! :)

fujinet-bill-add-slots.thumb.png.247e5b1bb29b024d99363b4a2c949ecf.png

 

 

  • Like 2

Share this post


Link to post
Share on other sites

#Atari8bit #FujiNET Happy Holidays, everyone! In this video, I show how I use the NCD and NTRANS tools, coupled with AtariWriter, to take a document prepared in AtariWriter, convert it to HTML, and upload to a web server!

 

  • Like 4

Share this post


Link to post
Share on other sites

Trying to debug some slow connection issues with my FujiNet, and did a ping from my laptop to the device is showing lots of delays also:

 ~/ ping 192.168.7.95
PING 192.168.7.95 (192.168.7.95): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 192.168.7.95: icmp_seq=0 ttl=255 time=1974.071 ms
64 bytes from 192.168.7.95: icmp_seq=1 ttl=255 time=968.975 ms
64 bytes from 192.168.7.95: icmp_seq=2 ttl=255 time=119.691 ms
64 bytes from 192.168.7.95: icmp_seq=3 ttl=255 time=337.084 ms
64 bytes from 192.168.7.95: icmp_seq=4 ttl=255 time=156.458 ms
64 bytes from 192.168.7.95: icmp_seq=5 ttl=255 time=455.994 ms
64 bytes from 192.168.7.95: icmp_seq=6 ttl=255 time=392.526 ms
64 bytes from 192.168.7.95: icmp_seq=7 ttl=255 time=258.150 ms
64 bytes from 192.168.7.95: icmp_seq=8 ttl=255 time=29.688 ms
64 bytes from 192.168.7.95: icmp_seq=9 ttl=255 time=62.428 ms
64 bytes from 192.168.7.95: icmp_seq=10 ttl=255 time=68.860 ms
64 bytes from 192.168.7.95: icmp_seq=11 ttl=255 time=85.676 ms
64 bytes from 192.168.7.95: icmp_seq=12 ttl=255 time=142.969 ms
64 bytes from 192.168.7.95: icmp_seq=13 ttl=255 time=129.644 ms
64 bytes from 192.168.7.95: icmp_seq=14 ttl=255 time=154.282 ms
64 bytes from 192.168.7.95: icmp_seq=15 ttl=255 time=357.408 ms
64 bytes from 192.168.7.95: icmp_seq=16 ttl=255 time=279.075 ms
64 bytes from 192.168.7.95: icmp_seq=17 ttl=255 time=377.877 ms
64 bytes from 192.168.7.95: icmp_seq=18 ttl=255 time=34.734 ms
64 bytes from 192.168.7.95: icmp_seq=19 ttl=255 time=57.927 ms
64 bytes from 192.168.7.95: icmp_seq=20 ttl=255 time=79.694 ms
64 bytes from 192.168.7.95: icmp_seq=21 ttl=255 time=104.341 ms
64 bytes from 192.168.7.95: icmp_seq=22 ttl=255 time=218.571 ms
64 bytes from 192.168.7.95: icmp_seq=23 ttl=255 time=222.047 ms
64 bytes from 192.168.7.95: icmp_seq=24 ttl=255 time=224.042 ms
64 bytes from 192.168.7.95: icmp_seq=25 ttl=255 time=290.663 ms
^C
--- 192.168.7.95 ping statistics ---
26 packets transmitted, 26 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.688/291.649/1974.071/386.567 ms

As a comparison, from my laptop to my Synology - both are within 5 feet of each other and the wifi access point:

 ~/ ping synology.local
PING synology.local (192.168.7.93): 56 data bytes
64 bytes from 192.168.7.93: icmp_seq=0 ttl=64 time=5.804 ms
64 bytes from 192.168.7.93: icmp_seq=1 ttl=64 time=4.334 ms
64 bytes from 192.168.7.93: icmp_seq=2 ttl=64 time=4.374 ms
64 bytes from 192.168.7.93: icmp_seq=3 ttl=64 time=2.553 ms
64 bytes from 192.168.7.93: icmp_seq=4 ttl=64 time=2.972 ms
64 bytes from 192.168.7.93: icmp_seq=5 ttl=64 time=1.509 ms
64 bytes from 192.168.7.93: icmp_seq=6 ttl=64 time=5.046 ms
64 bytes from 192.168.7.93: icmp_seq=7 ttl=64 time=2.617 ms
64 bytes from 192.168.7.93: icmp_seq=8 ttl=64 time=2.067 ms
64 bytes from 192.168.7.93: icmp_seq=9 ttl=64 time=3.434 ms
64 bytes from 192.168.7.93: icmp_seq=10 ttl=64 time=2.011 ms
^C
--- synology.local ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.509/3.338/5.804/1.316 ms

 

Share this post


Link to post
Share on other sites
58 minutes ago, tsom said:

Trying to debug some slow connection issues with my FujiNet, and did a ping from my laptop to the device is showing lots of delays also:

Will be interesting to see the comparison with the new v1.3

Share this post


Link to post
Share on other sites
2 hours ago, tsom said:

Trying to debug some slow connection issues with my FujiNet, and did a ping from my laptop to the device is showing lots of delays also

 

1 hour ago, Mr Robot said:

I'm getting similar results with the 1.3 revision of the NUC+ daughterboard

@MrFSL

 

I've disabled WiFi power saving in the latest firmware build and have much better ping results. Please upgrade and test again

 

Before

--- fujinet ping statistics ---
15 packets transmitted, 14 received, 6% packet loss, time 14047ms
rtt min/avg/max/mdev = 14.381/71.239/207.692/46.640 ms

vs After

--- fujinet ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14023ms
rtt min/avg/max/mdev = 2.387/4.224/10.857/2.166 ms


 

Share this post


Link to post
Share on other sites

Mine, Before:

Pinging 192.168.1.11 with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=108ms TTL=255
Reply from 192.168.1.11: bytes=32 time=20ms TTL=255
Reply from 192.168.1.11: bytes=32 time=28ms TTL=255
Reply from 192.168.1.11: bytes=32 time=43ms TTL=255
Reply from 192.168.1.11: bytes=32 time=42ms TTL=255
Reply from 192.168.1.11: bytes=32 time=47ms TTL=255
Reply from 192.168.1.11: bytes=32 time=50ms TTL=255
Reply from 192.168.1.11: bytes=32 time=62ms TTL=255
Reply from 192.168.1.11: bytes=32 time=72ms TTL=255
Reply from 192.168.1.11: bytes=32 time=84ms TTL=255
Reply from 192.168.1.11: bytes=32 time=93ms TTL=255
Reply from 192.168.1.11: bytes=32 time=104ms TTL=255
Reply from 192.168.1.11: bytes=32 time=110ms TTL=255
Reply from 192.168.1.11: bytes=32 time=21ms TTL=255
Reply from 192.168.1.11: bytes=32 time=33ms TTL=255
Reply from 192.168.1.11: bytes=32 time=47ms TTL=255
Reply from 192.168.1.11: bytes=32 time=40ms TTL=255
Reply from 192.168.1.11: bytes=32 time=43ms TTL=255
Reply from 192.168.1.11: bytes=32 time=61ms TTL=255
Reply from 192.168.1.11: bytes=32 time=72ms TTL=255
Reply from 192.168.1.11: bytes=32 time=87ms TTL=255
Reply from 192.168.1.11: bytes=32 time=105ms TTL=255
Reply from 192.168.1.11: bytes=32 time=112ms TTL=255
Reply from 192.168.1.11: bytes=32 time=17ms TTL=255
Reply from 192.168.1.11: bytes=32 time=21ms TTL=255
Reply from 192.168.1.11: bytes=32 time=34ms TTL=255
Reply from 192.168.1.11: bytes=32 time=46ms TTL=255

Ping statistics for 192.168.1.11:
    Packets: Sent = 27, Received = 27, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 112ms, Average = 59ms

_AFTER_:

C:\Users\thomc>ping -t thom

Pinging thom.home [192.168.1.11] with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=6ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=9ms TTL=255
Reply from 192.168.1.11: bytes=32 time=5ms TTL=255
Reply from 192.168.1.11: bytes=32 time=26ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=4ms TTL=255
Reply from 192.168.1.11: bytes=32 time=2ms TTL=255
Reply from 192.168.1.11: bytes=32 time=4ms TTL=255

Ping statistics for 192.168.1.11:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 26ms, Average = 6ms
Control-C
^C
C:\Users\thomc>

..........WOW.............

 

-Thom

  • Like 1

Share this post


Link to post
Share on other sites

Ok....can’t wait to get a chance to update!

 

Updated. And WOW also:

 ~/ ping 192.168.7.95
PING 192.168.7.95 (192.168.7.95): 56 data bytes
64 bytes from 192.168.7.95: icmp_seq=0 ttl=255 time=150.070 ms
64 bytes from 192.168.7.95: icmp_seq=1 ttl=255 time=3.515 ms
64 bytes from 192.168.7.95: icmp_seq=2 ttl=255 time=3.623 ms
64 bytes from 192.168.7.95: icmp_seq=3 ttl=255 time=15.886 ms
64 bytes from 192.168.7.95: icmp_seq=4 ttl=255 time=4.165 ms
64 bytes from 192.168.7.95: icmp_seq=5 ttl=255 time=5.955 ms
64 bytes from 192.168.7.95: icmp_seq=6 ttl=255 time=4.459 ms
64 bytes from 192.168.7.95: icmp_seq=7 ttl=255 time=16.374 ms
64 bytes from 192.168.7.95: icmp_seq=8 ttl=255 time=3.609 ms
64 bytes from 192.168.7.95: icmp_seq=9 ttl=255 time=3.407 ms
64 bytes from 192.168.7.95: icmp_seq=10 ttl=255 time=4.437 ms
64 bytes from 192.168.7.95: icmp_seq=11 ttl=255 time=10.810 ms
64 bytes from 192.168.7.95: icmp_seq=12 ttl=255 time=7.610 ms
64 bytes from 192.168.7.95: icmp_seq=13 ttl=255 time=4.566 ms
64 bytes from 192.168.7.95: icmp_seq=14 ttl=255 time=2.651 ms
64 bytes from 192.168.7.95: icmp_seq=15 ttl=255 time=3.285 ms
64 bytes from 192.168.7.95: icmp_seq=16 ttl=255 time=38.384 ms
64 bytes from 192.168.7.95: icmp_seq=17 ttl=255 time=4.468 ms
64 bytes from 192.168.7.95: icmp_seq=18 ttl=255 time=4.598 ms
64 bytes from 192.168.7.95: icmp_seq=19 ttl=255 time=27.260 ms
64 bytes from 192.168.7.95: icmp_seq=20 ttl=255 time=9.620 ms
64 bytes from 192.168.7.95: icmp_seq=21 ttl=255 time=2.534 ms
64 bytes from 192.168.7.95: icmp_seq=22 ttl=255 time=9.424 ms
64 bytes from 192.168.7.95: icmp_seq=23 ttl=255 time=43.461 ms
64 bytes from 192.168.7.95: icmp_seq=24 ttl=255 time=13.408 ms
64 bytes from 192.168.7.95: icmp_seq=25 ttl=255 time=3.235 ms
64 bytes from 192.168.7.95: icmp_seq=26 ttl=255 time=2.351 ms
64 bytes from 192.168.7.95: icmp_seq=27 ttl=255 time=19.447 ms
^C
--- 192.168.7.95 ping statistics ---
28 packets transmitted, 28 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.351/15.093/150.070/27.984 ms
 ~/

Connecting to TNFS servers, both my local RPi and on the internets is MUCH faster. Thanks @mozzwald

Edited by tsom
  • Like 1

Share this post


Link to post
Share on other sites

Before:

Before.png.36d62cb8243dd88c70ddb427a7aea8d5.png

 

After:

After.png.39024ca08560ccc708b502067385ff14.png

 

Technically my average rate is higher on the "after" ;) --- but obviously that is due to the hardware issues I am having. The individual ping rates are vastly improved! When I get some time to play around I think this is going to make things much better even with my interference issues.

 

Thanks @mozzwald

 

 

Share this post


Link to post
Share on other sites

I will put my questions up front and then my observations after.

 

1) When switching to sio2bt will they Fujinet always go back to the last speed it was set at? (Perhaps we can figure a way for SAM to let us know?)

 

2) Could it be possible for the hardware to remember that you last used bluetooth and so power up to sio2bt instead of defaulting to the Fujinet networking mode?

 

 

OBSERVATIONS:

Alas - I still need a bit of Fuji-foil (tm) to keep things running. Bluetooth at 58660 runs remarkably reliable with the foil and sio2bsd.

image.png.b9df542e81d2101fedb527afb3f48dd0.png

 

 

 

Network functionality is definitely improved. When doing a bunch of IO across the local intranet, pings still slow down even with the Fuji-foil. (This was me copying a bunch of data to a ATR hosted on TNFS on my local network.)

image.png.2bc714d2db774a0b008f490f07a16a78.png

 

As bad as this looks - this is the first time copying files like this has worked for me at all (although it is painfully slow.) So in all a massive improvement. Here we might just be running into the limitations of the hardware when under load?

 

 

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, MrFSL said:

2) Could it be possible for the hardware to remember that you last used bluetooth and so power up to sio2bt instead of defaulting to the Fujinet networking mode?

Seems possible. Would need to add a configuration option that gets saved to SD card/SPIFFS. Can you please open an issue at https://github.com/FujiNetWIFI/fujinet-platformio/issues

 

3 hours ago, MrFSL said:

Network functionality is definitely improved. When doing a bunch of IO across the local intranet, pings still slow down even with the Fuji-foil. (This was me copying a bunch of data to a ATR hosted on TNFS on my local network.)

Lol, FujiFoil ™️ :D Glad it's working better. Now we need to figure out that Sophia Fuji problem...

Share this post


Link to post
Share on other sites
50 minutes ago, mozzwald said:

Lol, FujiFoil ™️ :D Glad it's working better. Now we need to figure out that Sophia Fuji problem

 

Its more than the Sophia. Pretty much if power runs through it and I move it close it disrupts. The IDE+ will disrupt it. My USB card reader will disrupt it.

 

My RF buddy gave me some suggestions though he never looked at the Fujinet: 

a) the antenna is mismatched (wrong length) or

b) it has the wrong value filter caps so it's not attenuating unwanted frequencies 

 

--- I replied that it is an "all in one" unit and sent him the espressif build docs. 

--- Meanwhile if you want to start a FujiFoil ™️ interest/pre-order thread I could ramp up manufacturing. I was thinking we could charge 91.85 KWD. 

 

1 hour ago, mozzwald said:

Hopefully it is detailed enough. I didn't bother to read before I posted... cause ya know... lazy and all.

 

https://github.com/FujiNetWIFI/fujinet-platformio/issues/419

 

Share this post


Link to post
Share on other sites
18 hours ago, mozzwald said:

I've disabled WiFi power saving in the latest firmware build and have much better ping results. Please upgrade and test again

So the question is how much additional power is consumed in this operation mode?   and the next question, How the change will affect people with standard configuration? like 65XE low power  original powers supply: is this power supply enough to power the computer + fujinet?

Share this post


Link to post
Share on other sites
1 hour ago, MrFSL said:

--- I replied that it is an "all in one" unit and sent him the espressif build docs. 

Good call. There's nothing we can do about the antenna design other than follow their recommended design docs.

1 hour ago, MrFSL said:

Hopefully it is detailed enough.

Looks good, thanks

1 hour ago, manterola said:

So the question is how much additional power is consumed in this operation mode?

Good question. I dunno, did not check consumption. I did test SIO power only, 12W Apple USB charger on with my 800XL and it worked.

1 hour ago, manterola said:

How the change will affect people with standard configuration? like 65XE low power  original powers supply: is this power supply enough to power the computer + fujinet?

We need someone with that configuration to test it.

Share this post


Link to post
Share on other sites
1 hour ago, mozzwald said:

Good call. There's nothing we can do about the antenna design other than follow their recommended design docs.

Looks good, thanks

Good question. I dunno, did not check consumption. I did test SIO power only, 12W Apple USB charger on with my 800XL and it worked.

We need someone with that configuration to test it.

Probably it will work. I would love to test old vs new firmware power consumption but my usb meter has been in the last weeks somewhere between China and USA. 

Share this post


Link to post
Share on other sites

Well... I don't plan on rolling back the firmware... but if it is helpful

 

This is with NO FUJINET:

image.png.3031c9fd3556be989d650064172d6d87.png

 

This is WITH FUJINET (latest firmware):

image.png.b8bfb046a887ee16a136b1c0454ebe4f.png

 

  • Like 2

Share this post


Link to post
Share on other sites

 

Quote

 * Can now skip WiFi setup in CONFIG

 

Hallelujah and praise the Fuji-gods.

 

Yeah, and that makes me happy. (Correction, on my previous post... I was not running the LATEST... I was running the one before this one.) Can't wait to do some testing.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...