Mr Robot Posted August 1, 2020 Share Posted August 1, 2020 I have some DSS12UTR left over from the beta Fujinet builds, it looks to be an equivalent part, will that do? The diode needs to go here I think, those 4 pins at the bottom are not connected to the XEL board. That gives me 4mm gap so there's plenty of room. 56 minutes ago, Mr Robot said: If you're not up for the challenge you could send me your Sparkfun board I'm up for the challenge but I think the majority of XEL owners will balk at the idea of doing this. Most XEL owners have this board soldered into the XEL and it's pretty densely surrounded by components. Is everyone going to have to do this (if it works) to their XEL if they want to use a Fujinet with it? Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 1, 2020 Share Posted August 1, 2020 9 minutes ago, Mr Robot said: I have some DSS12UTR left over from the beta Fujinet builds, it looks to be an equivalent part, will that do? The diode needs to go here I think, those 4 pins at the bottom are not connected to the XEL board. That gives me 4mm gap so there's plenty of room. Yes, that DSS12UTR will work fine. Ah, I didn't see there's 2 TX pins on the board, so yes, use the one that runs to the motherboard. 14 minutes ago, Mr Robot said: Most XEL owners have this board soldered into the XEL and it's pretty densely surrounded by components. Is everyone going to have to do this (if it works) to their XEL if they want to use a Fujinet with it? Let's see if this works and then figure out what to do moving forward. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 3, 2020 Share Posted August 3, 2020 OK I can confirm that soldering the diode to the FTDI board stops the Fujinet having boot issues. I've tested it with othe rSIO devices and they all work too, I haven't yet tested the SIO2PC-USB to see if that still works, I expect it will. I'm still confused as to why the Fujinet needs this but nothing else does? Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted August 3, 2020 Share Posted August 3, 2020 45 minutes ago, Mr Robot said: OK I can confirm that soldering the diode to the FTDI board stops the Fujinet having boot issues. Query - did you cut the trace on the FTDI board underneath the SMD diode you installed? Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 3, 2020 Share Posted August 3, 2020 Yes of course! It wouldn't do a lot of good if I hadn't 2 Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 3, 2020 Share Posted August 3, 2020 1 hour ago, Mr Robot said: OK I can confirm that soldering the diode to the FTDI board stops the Fujinet having boot issues. I've tested it with othe rSIO devices and they all work too, I haven't yet tested the SIO2PC-USB to see if that still works, I expect it will. I'm still confused as to why the Fujinet needs this but nothing else does? Thanks for testing. The FT232 is not open collector and the diode simulates it. A proper buffer on FujiNet would probably make it work but your FT232 is still not open collector and some other devices may not work. It's the same issue with SDrives and the like. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 3, 2020 Author Share Posted August 3, 2020 (At the risk of agitation...) What's the correct fix? -Thom Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 3, 2020 Share Posted August 3, 2020 6 minutes ago, tschak909 said: (At the risk of agitation...) What's the correct fix? -Thom The "correct" fix is to add a buffer to the FujiNet and a buffer to the FT232/1088XEL. Better question is "what is the right fix" I will look into adding a buffer to FujiNet, but the ones already in the wild now will not be getting a buffer chip. It'll take another prototype revision. I understand not everyone is skilled at soldering, but the diode fix to the Sparkfun board seems 'easiest'. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 3, 2020 Share Posted August 3, 2020 25 minutes ago, mozzwald said: It's the same issue with SDrives and the like. Except that an SDrive-Max, without a diode or UNO2SIO board will still work fine with the XEL, as long as it's the only one trying to load anything. Also the SDrive if plugged in to any other Atari at the same time as another device, doesn't work without the extra hardware, but the Fujinet does. As you said; you tried it with two 1050's and 2 Fujinets and it all works OK. The SDrive screwed up as soon as it was plugged in with another device. Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 3, 2020 Share Posted August 3, 2020 18 minutes ago, Mr Robot said: Except that an SDrive-Max, without a diode or UNO2SIO board will still work fine with the XEL, as long as it's the only one trying to load anything. I understand. The open-collector issue is still the same though, no matter it be the SIO2PC/FT232, FujiNet, or SDrive. If you removed the diode on the FujiNet TX line and bridged it, it might work with the unmodified FT232 board in your 1088XEL, but then it won't play well with other devices on the bus. Have you tried a diode fixed SDrive with the unmodified FT232 on the 1088XEL? I suspect it would have problems similar to what you see with the FujiNet. Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 3, 2020 Share Posted August 3, 2020 24 minutes ago, mozzwald said: Have you tried a diode fixed SDrive with the unmodified FT232 on the 1088XEL? No I didn't get an Sdrive until after @BigBen created the UNO2SIO circuit. I think @DrVenkman might have tried just a diode on the UNO with his XEL but I'll take your word for it. I'm sorry if this means you have to do another hardware revision Next question, how do I change the baud rate on the Fujinet flasher so my old mac can keep up? I failed miserably at getting gkt3/python3.8/wxpython to compile on a Raspberry Pi Quote Link to comment Share on other sites More sharing options...
mozzwald Posted August 3, 2020 Share Posted August 3, 2020 29 minutes ago, Mr Robot said: I'm sorry if this means you have to do another hardware revision Better to figure this out early 29 minutes ago, Mr Robot said: Next question, how do I change the baud rate on the Fujinet flasher so my old mac can keep up? I failed miserably at getting gkt3/python3.8/wxpython to compile on a Raspberry Pi That's not quite as easy as it sounds. Baud rates are built into the firmware and the flash tool. Unfortunately, my 'vintage' macbook air maxes out with High Sierra so I can't even test the mac flasher. I tried CoolTerm for mac but it won't let me go up to 921600. I had to follow this which works, but the line endings are messed up and make it hard to read. Instead, you might wanna open the Fujinet Flasher, click the serial debug button, then in terminal run: sudo stty -f /dev/cu.SLAB_USBtoUART 921600 Quote Link to comment Share on other sites More sharing options...
jamm Posted August 4, 2020 Share Posted August 4, 2020 1 hour ago, mozzwald said: Better to figure this out early That's not quite as easy as it sounds. Baud rates are built into the firmware and the flash tool. Unfortunately, my 'vintage' macbook air maxes out with High Sierra so I can't even test the mac flasher. I tried CoolTerm for mac but it won't let me go up to 921600. I had to follow this which works, but the line endings are messed up and make it hard to read. Instead, you might wanna open the Fujinet Flasher, click the serial debug button, then in terminal run: sudo stty -f /dev/cu.SLAB_USBtoUART 921600 I think the only baud rate built into the firmware is for the debug output, not the flashing of the board, if I remember correctly. Anyway, we could certainly go slower. I tried some different speeds a while back and found that the current baud setting is faster than the flash on the board will take the update data, so we could go slower without it actually taking longer to update firmware. We'll have to play around with values to see where the cut-off speed is. 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted August 4, 2020 Share Posted August 4, 2020 I received my FujiNet today (thanks), but have been unable to test it yet because of bad video. I can still hear it boot the BBS, but I can't see a thing. I tried a different monitor cable, but still no luck. I think it's more likely that my old Gateway 24" monitor died than a problem with the 800. I will check it out and report back as soon as I have time. All I can say at this point is: 'Wonderful build quality'. It looks very nicely made. :) 2 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 4, 2020 Share Posted August 4, 2020 2 hours ago, jamm said: I think the only baud rate built into the firmware is for the debug output, not the flashing of the board, if I remember correctly. That's handy then, it's flashing the firmware ok, no errors showing up at leat but the debug output is messed up garbage mixed with real text so we think it's the baud rate there Quote Link to comment Share on other sites More sharing options...
jamm Posted August 4, 2020 Share Posted August 4, 2020 5 minutes ago, Mr Robot said: That's handy then, it's flashing the firmware ok, no errors showing up at leat but the debug output is messed up garbage mixed with real text so we think it's the baud rate there Have any idea what baud rate your Mac can reliably handle? Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 4, 2020 Share Posted August 4, 2020 10 hours ago, jamm said: Have any idea what baud rate your Mac can reliably handle? not a clue! Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted August 4, 2020 Share Posted August 4, 2020 19 minutes ago, Mr Robot said: not a clue! How old is your Mac? My last daily-driver Mac was a 2011 Macbook Pro. It could easily do 125kbps through an FTDS USB-serial device I use as an SIO2PC with RespeQt. Quote Link to comment Share on other sites More sharing options...
jamm Posted August 4, 2020 Share Posted August 4, 2020 My only concern is that slowing that debug output too much may negatively affect timing with the Atari over SIO. We'll have to test to see at what point that starts to happen. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 4, 2020 Share Posted August 4, 2020 (edited) 20 hours ago, Mr Robot said: OK I can confirm that soldering the diode to the FTDI board stops the Fujinet having boot issues. I've tested it with othe rSIO devices and they all work too, I haven't yet tested the SIO2PC-USB to see if that still works, I expect it will. I'm still confused as to why the Fujinet needs this but nothing else does? It was theorized that the spark fun would lead to issues without modification, after the whole switch positions and low forward voltage drop diode discussions. Looks like it proved to be true and it's nice to know how simple the fix is... not sure which will bleed more current due to forward voltage loss.... buffering or diode... depends on the choice of each while still handling the highest speed of SIO or future external SIO clocking... long SIO chains can get too loaded down with Atari peripherals all line up like we do... should be interesting Edited August 4, 2020 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
+mytek Posted August 4, 2020 Share Posted August 4, 2020 18 hours ago, mozzwald said: The "correct" fix is to add a buffer to the FujiNet and a buffer to the FT232/1088XEL. Better question is "what is the right fix" Mr Robot brought this issue to my attention last week, but I was a bit distracted by my latest board development to really pay it much heed. Anyway now having focused on what has been discussed, yes the root of the problem is the choice, and more specifically the method I employed at implementing the SparkFun BOB-12731 FTDI board for the SIO2PC connection on the 1088XEL. It isn't a fully isolated device apparently, and seems to be exhibiting some pullup of the SIO signal lines it connects to. This isn't a problem with most other Atari SIO peripherals which have a strong ability to sink their signals to ground. However devices that use a diode to achieve an open collector output such as FujiNet will struggle to pull the signal low enough to look like a proper communication is being sent. This was solved on the SDrive-MAX by creating an interface board with the buffer chip you've been talking about. I believe they used something like a 74LS07 or equivalent, which is an open collector hex buffer (6 buffers contained in one package). There is an SMD dual gate open drain buffer that would probably work quite well, while also not taking much space (SN74LVC2G07) and is available from Digi-Key as P/N 296-13494-1-ND costing only $0.39 in single quantities. Quote I will look into adding a buffer to FujiNet, but the ones already in the wild now will not be getting a buffer chip. It'll take another prototype revision. This would be ideal, since the 1088XEL has been in production and offered as DIY for 3 years now, with quite a few out in the field. And it wouldn't be practical to expect all of those systems to be modified. Edit: although I could see adding the SMT diode to the FTDI board from this point forward in all 1088XEL builds just to be on the safe side, and to better accommodate future SIO devices. Quote I understand not everyone is skilled at soldering, but the diode fix to the Sparkfun board seems 'easiest'. Yes Mr Robot's solution is good where someone wishes to use the current rev of FujiNet hardware, but obviously not ideal for the unskilled to implement on their own. --------------- Also I was thinking that for the current crop of FujiNet devices that maybe there is a better diode to be used. Something with a much lower voltage drop. Without scanning through this the original very long FujiNet thread, I don't know what you are presently using and whether that is perhaps already the best device you can find. 2 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted August 4, 2020 Share Posted August 4, 2020 Mine's a MacBook Air "Core i7" 1.7 13" 8/512GB (Mid-2013) Interesting. I did another firmware update this morning and my mac seems to be behaving itself now. I'm still getting a little junk at the beginning of the process but it quickly corrects itself. Did Thom cast a spell on it? Spoiler Using '/dev/cu.SLAB_USBtoUART' as serial port. Showing logs: [10:28:31]NNaaBpFF #v)meN%k!%kzJ{֜0(w [10:28:31]2 0 9 [10:28:31]Ntitret 1 [10:28:31]CF: 31 3f 000Fujie necpsD:dis i_rcs( [10:28:31]ksopoes)ACK [10:28:31]oHI INE [10:28:31]Orte ye [10:28:31]!si SODX->SI wi1btsCOMPEE [10:28:31]!si SODX->SI wi1btsCOMPEE Serial port closed! [10:28:32] [10:28:32]CF: 08 fe 08 fe 08 [10:28:32]CHECKSUM_ERROR [10:28:32] [10:28:32]CF: 08 fe 08 fe 08 [10:28:32]CHECKSUM_ERROR [10:28:32]Toggling baudrate from 19200 to 67431 [10:28:32]set_baudrate change from 19200 to 67431 [10:28:32] [10:28:32]CF: 31 53 00 00 84 [10:28:32]FujiNet intercepts D1: [10:28:32]disk sio_process() [10:28:32]ignoring status command [10:28:32] . . . [10:28:35]CF: 31 52 68 00 eb [10:28:35]FujiNet intercepts D1: [10:28:35]disk sio_process() [10:28:35]ACK! [10:28:35]disk READ [10:28:35]ATR READ [10:28:35]->SIO write 128 bytes [10:28:35]COMPLETE! [10:28:35] [10:28:35]CF: 31 52 69 00 ec [10:28:35]FujiNet intercepts D1: [10:28:35]disk sio_process() [10:28:35]ACK! [10:28:35]disk READ [10:28:35]ATR READ [10:28:35]->SIO write 128 bytes [10:28:35]COMPLETE! [10:28:35] [10:28:35]CF: 00 38 00 00 f8 [10:28:35]CHECKSUM_ERROR [10:28:35] [10:28:35]CF: 00 38 00 00 f8 [10:28:35]CHECKSUM_ERROR [10:28:35]Toggling baudrate from 67431 to 19200 [10:28:35]set_baudrate change from 67432 to 19200 [10:28:35] [10:28:35]CF: 70 fe 00 00 6f [10:28:35]sioFuji::sio_process() called [10:28:35]ACK! [10:28:35]Fuji cmd: GET SSID [10:28:35]->SIO write 96 bytes [10:28:35]COMPLETE! [10:28:35] [10:28:35]CF: 70 e8 00 00 59 [10:28:35]sioFuji::sio_process() called [10:28:35]ACK! [10:28:35]Fuji cmd: GET ADAPTER CONFIG [10:28:35]->SIO write 139 bytes [10:28:35]COMPLETE! [10:28:35] [10:28:35]CF: 70 fd 00 00 6e [10:28:35]sioFuji::sio_process() called [10:28:35]ACK! [10:28:35]Fuji cmd: SCAN NETWORKS [10:28:37]WIFI_EVENT_SCAN_DONE [10:28:37]esp_wifi_scan returned 3 results [10:28:37]->SIO write 4 bytes [10:28:37]COMPLETE! [10:28:37] [10:28:37]CF: 70 fc 00 00 6d [10:28:37]sioFuji::sio_process() called [10:28:37]ACK! [10:28:37]Fuji cmd: GET SCAN RESULT [10:28:37]->SIO write 33 bytes [10:28:37]COMPLETE! [10:28:37] [10:28:37]CF: 70 fc 01 00 6e [10:28:37]sioFuji::sio_process() called [10:28:37]ACK! [10:28:37]Fuji cmd: GET SCAN RESULT [10:28:37]->SIO write 33 bytes [10:28:37]COMPLETE! [10:28:37] [10:28:37]CF: 70 fc 02 00 6f [10:28:37]sioFuji::sio_process() called [10:28:37]ACK! [10:28:37]Fuji cmd: GET SCAN RESULT [10:28:37]->SIO write 33 bytes [10:28:37]COMPLETE! [10:29:06] [10:29:06]CF: 70 fc 02 00 6f [10:29:06]sioFuji::sio_process() called [10:29:06]ACK! [10:29:06]Fuji cmd: GET SCAN RESULT [10:29:06]->SIO write 33 bytes [10:29:06]COMPLETE! [10:29:06] [10:29:06]CF: 70 fb 00 00 6c [10:29:06]sioFuji::sio_process() called [10:29:06]ACK! [10:29:06]Fuji cmd: SET SSID [10:29:06]<-SIO read 96 bytes [10:29:06]ACK! [10:29:06]Connecting to net: Gryffindor password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [10:29:06]WiFi connect attempt to SSID "Gryffindor" [10:29:06]esp_wifi_connect returned 0 [10:29:06]COMPLETE! [10:29:06] [10:29:06]CF: 70 fa 00 00 6b [10:29:06]sioFuji::sio_process() called [10:29:06]ACK! [10:29:06]Fuji cmd: GET WIFI STATUS [10:29:06]->SIO write 1 bytes [10:29:06]COMPLETE! [10:29:06] [10:29:06]CF: 70 fa 00 00 6b [10:29:06]sioFuji::sio_process() called [10:29:06]ACK! [10:29:06]Fuji cmd: GET WIFI STATUS [10:29:06]->SIO write 1 bytes [10:29:06]COMPLETE! [10:29:07] [10:29:07]CF: 70 fa 00 00 6b [10:29:07]sioFuji::sio_process() called [10:29:07]ACK! [10:29:07]Fuji cmd: GET WIFI STATUS [10:29:07]->SIO write 1 bytes [10:29:07]COMPLETE! [10:29:07] [10:29:07]CF: 70 fa 00 00 6b [10:29:07]sioFuji::sio_process() called [10:29:07]ACK! [10:29:07]Fuji cmd: GET WIFI STATUS [10:29:07]->SIO write 1 bytes [10:29:07]COMPLETE! [10:29:09] [10:29:09]CF: 70 fa 00 00 6b [10:29:09]sioFuji::sio_process() called [10:29:09]ACK! [10:29:09]Fuji cmd: GET WIFI STATUS [10:29:09]->SIO write 1 bytes [10:29:09]COMPLETE! [10:29:09] [10:29:09]CF: 70 fa 00 00 6b [10:29:09]sioFuji::sio_process() called [10:29:09]ACK! [10:29:09]Fuji cmd: GET WIFI STATUS [10:29:09]->SIO write 1 bytes [10:29:09]COMPLETE! [10:29:10] [10:29:10]CF: 70 fa 00 00 6b [10:29:10]sioFuji::sio_process() called [10:29:10]ACK! [10:29:10]Fuji cmd: GET WIFI STATUS [10:29:10]->SIO write 1 bytes [10:29:10]COMPLETE! [10:29:10] [10:29:10]CF: 70 fa 00 00 6b [10:29:10]sioFuji::sio_process() called [10:29:10]ACK! [10:29:10]Fuji cmd: GET WIFI STATUS [10:29:10]->SIO write 1 bytes [10:29:10]COMPLETE! [10:29:11] [10:29:11]CF: 70 fa 00 00 6b [10:29:11]sioFuji::sio_process() called [10:29:11]ACK! [10:29:11]Fuji cmd: GET WIFI STATUS [10:29:11]->SIO write 1 bytes [10:29:11]COMPLETE! [10:29:11] [10:29:11]CF: 70 fa 00 00 6b [10:29:11]sioFuji::sio_process() called [10:29:11]ACK! [10:29:11]Fuji cmd: GET WIFI STATUS [10:29:11]->SIO write 1 bytes [10:29:11]COMPLETE! [10:29:13] [10:29:13]CF: 70 fa 00 00 6b [10:29:13]sioFuji::sio_process() called [10:29:13]ACK! [10:29:13]Fuji cmd: GET WIFI STATUS [10:29:13]->SIO write 1 bytes [10:29:13]COMPLETE! [10:29:13] [10:29:13]CF: 70 fa 00 00 6b [10:29:13]sioFuji::sio_process() called [10:29:13]ACK! [10:29:13]Fuji cmd: GET WIFI STATUS [10:29:13]->SIO write 1 bytes [10:29:13]COMPLETE! [10:29:14] [10:29:14]CF: 70 fa 00 00 6b [10:29:14]sioFuji::sio_process() called [10:29:14]ACK! [10:29:14]Fuji cmd: GET WIFI STATUS [10:29:14]->SIO write 1 bytes [10:29:14]COMPLETE! [10:29:14] [10:29:14]CF: 70 fa 00 00 6b [10:29:14]sioFuji::sio_process() called [10:29:14]ACK! [10:29:14]Fuji cmd: GET WIFI STATUS [10:29:14]->SIO write 1 bytes [10:29:14]COMPLETE! [10:29:15] [10:29:15]CF: 70 fa 00 00 6b [10:29:15]sioFuji::sio_process() called [10:29:15]ACK! [10:29:15]Fuji cmd: GET WIFI STATUS [10:29:15]->SIO write 1 bytes [10:29:15]COMPLETE! [10:29:15] [10:29:15]CF: 70 fa 00 00 6b [10:29:15]sioFuji::sio_process() called [10:29:15]ACK! [10:29:15]Fuji cmd: GET WIFI STATUS [10:29:15]->SIO write 1 bytes [10:29:15]COMPLETE! [10:29:19] [10:29:19]CF: 70 e8 00 00 59 [10:29:19]sioFuji::sio_process() called [10:29:19]ACK! [10:29:19]Fuji cmd: GET ADAPTER CONFIG [10:29:19]->SIO write 139 bytes [10:29:19]COMPLETE! [10:29:19] [10:29:19]CF: 70 fd 00 00 6e [10:29:19]sioFuji::sio_process() called [10:29:19]ACK! [10:29:19]Fuji cmd: SCAN NETWORKS [10:29:21]WIFI_EVENT_SCAN_DONE [10:29:21]esp_wifi_scan returned 3 results [10:29:21]->SIO write 4 bytes [10:29:21]COMPLETE! [10:29:21] [10:29:21]CF: 70 fc 00 00 6d [10:29:21]sioFuji::sio_process() called [10:29:21]ACK! [10:29:21]Fuji cmd: GET SCAN RESULT [10:29:21]->SIO write 33 bytes [10:29:21]COMPLETE! [10:29:21] [10:29:21]CF: 70 fc 01 00 6e [10:29:21]sioFuji::sio_process() called [10:29:21]ACK! [10:29:21]Fuji cmd: GET SCAN RESULT [10:29:21]->SIO write 33 bytes [10:29:21]COMPLETE! [10:29:21] [10:29:21]CF: 70 fc 02 00 6f [10:29:21]sioFuji::sio_process() called [10:29:21]ACK! [10:29:21]Fuji cmd: GET SCAN RESULT [10:29:21]->SIO write 33 bytes [10:29:21]COMPLETE! And I'm back at the SSID list again, tried once more after blanking the logging window Spoiler Using '/dev/cu.SLAB_USBtoUART' as serial port. Showing logs: [10:34:31] [10:34:31]CF 0f 0 0 6 [10:34:31]:7 c10esiFj::orcsscalle [10:34:31]:7 c10esiFj::orcsscalle [10:34:31]ouisi_poe() dACK! [10:34:31]CNRST [10:34:31]Fuji cmd: GET SA EUL->SI wi3 bytes [10:34:31]ET [10:34:31]ET Serial port closed! [10:34:31] [10:34:31]CF: 70 fb 00 00 6c [10:34:31]sioFuji::sio_process() called [10:34:31]ACK! [10:34:31]Fuji cmd: SET SSID [10:34:31]<-SIO read 96 bytes [10:34:31]ACK! [10:34:31]Connecting to net: Gryffindor password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [10:34:31]WiFi connect attempt to SSID "Gryffindor" [10:34:31]esp_wifi_connect returned 0 [10:34:31]COMPLETE! [10:34:31] [10:34:31]CF: 70 fa 00 00 6b [10:34:31]sioFuji::sio_process() called [10:34:31]ACK! [10:34:31]Fuji cmd: GET WIFI STATUS [10:34:31]->SIO write 1 bytes [10:34:31]COMPLETE! [10:34:32] [10:34:32]CF: 70 fa 00 00 6b [10:34:32]sioFuji::sio_process() called [10:34:32]ACK! [10:34:32]Fuji cmd: GET WIFI STATUS [10:34:32]->SIO write 1 bytes [10:34:32]COMPLETE! [10:34:32] [10:34:32]CF: 70 fa 00 00 6b [10:34:32]sioFuji::sio_process() called [10:34:32]ACK! [10:34:32]Fuji cmd: GET WIFI STATUS [10:34:32]->SIO write 1 bytes [10:34:32]COMPLETE! [10:34:33] [10:34:33]CF: 70 fa 00 00 6b [10:34:33]sioFuji::sio_process() called [10:34:33]ACK! [10:34:33]Fuji cmd: GET WIFI STATUS [10:34:33]->SIO write 1 bytes [10:34:33]COMPLETE! [10:34:33] [10:34:33]CF: 70 fa 00 00 6b [10:34:33]sioFuji::sio_process() called [10:34:33]ACK! [10:34:33]Fuji cmd: GET WIFI STATUS [10:34:33]->SIO write 1 bytes [10:34:33]COMPLETE! [10:34:35] [10:34:35]CF: 70 fa 00 00 6b [10:34:35]sioFuji::sio_process() called [10:34:35]ACK! [10:34:35]Fuji cmd: GET WIFI STATUS [10:34:35]->SIO write 1 bytes [10:34:35]COMPLETE! [10:34:35] [10:34:35]CF: 70 fa 00 00 6b [10:34:35]sioFuji::sio_process() called [10:34:35]ACK! [10:34:35]Fuji cmd: GET WIFI STATUS [10:34:35]->SIO write 1 bytes [10:34:35]COMPLETE! [10:34:36] [10:34:36]CF: 70 fa 00 00 6b [10:34:36]sioFuji::sio_process() called [10:34:36]ACK! [10:34:36]Fuji cmd: GET WIFI STATUS [10:34:36]->SIO write 1 bytes [10:34:36]COMPLETE! [10:34:36] [10:34:36]CF: 70 fa 00 00 6b [10:34:36]sioFuji::sio_process() called [10:34:36]ACK! [10:34:36]Fuji cmd: GET WIFI STATUS [10:34:36]->SIO write 1 bytes [10:34:36]COMPLETE! [10:34:37] [10:34:37]CF: 70 fa 00 00 6b [10:34:37]sioFuji::sio_process() called [10:34:37]ACK! [10:34:37]Fuji cmd: GET WIFI STATUS [10:34:37]->SIO write 1 bytes [10:34:37]COMPLETE! [10:34:37] [10:34:37]CF: 70 fa 00 00 6b [10:34:37]sioFuji::sio_process() called [10:34:37]ACK! [10:34:37]Fuji cmd: GET WIFI STATUS [10:34:37]->SIO write 1 bytes [10:34:37]COMPLETE! [10:34:39] [10:34:39]CF: 70 fa 00 00 6b [10:34:39]sioFuji::sio_process() called [10:34:39]ACK! [10:34:39]Fuji cmd: GET WIFI STATUS [10:34:39]->SIO write 1 bytes [10:34:39]COMPLETE! [10:34:39] [10:34:39]CF: 70 fa 00 00 6b [10:34:39]sioFuji::sio_process() called [10:34:39]ACK! [10:34:39]Fuji cmd: GET WIFI STATUS [10:34:39]->SIO write 1 bytes [10:34:39]COMPLETE! [10:34:40] [10:34:40]CF: 70 fa 00 00 6b [10:34:40]sioFuji::sio_process() called [10:34:40]ACK! [10:34:40]Fuji cmd: GET WIFI STATUS [10:34:40]->SIO write 1 bytes [10:34:40]COMPLETE! [10:34:40] [10:34:40]CF: 70 fa 00 00 6b [10:34:40]sioFuji::sio_process() called [10:34:40]ACK! [10:34:40]Fuji cmd: GET WIFI STATUS [10:34:40]->SIO write 1 bytes [10:34:40]COMPLETE! [10:34:44] [10:34:44]CF: 70 e8 00 00 59 [10:34:44]sioFuji::sio_process() called [10:34:44]ACK! [10:34:44]Fuji cmd: GET ADAPTER CONFIG [10:34:44]->SIO write 139 bytes [10:34:44]COMPLETE! [10:34:44] [10:34:44]CF: 70 fd 00 00 6e [10:34:44]sioFuji::sio_process() called [10:34:44]ACK! [10:34:44]Fuji cmd: SCAN NETWORKS [10:34:45]WIFI_EVENT_SCAN_DONE [10:34:45]esp_wifi_scan returned 4 results [10:34:45]->SIO write 4 bytes [10:34:45]COMPLETE! [10:34:46] [10:34:46]CF: 70 fc 00 00 6d [10:34:46]sioFuji::sio_process() called [10:34:46]ACK! [10:34:46]Fuji cmd: GET SCAN RESULT [10:34:46]->SIO write 33 bytes [10:34:46]COMPLETE! [10:34:46] [10:34:46]CF: 70 fc 01 00 6e [10:34:46]sioFuji::sio_process() called [10:34:46]ACK! [10:34:46]Fuji cmd: GET SCAN RESULT [10:34:46]->SIO write 33 bytes [10:34:46]COMPLETE! [10:34:46] [10:34:46]CF: 70 fc 02 00 6f [10:34:46]sioFuji::sio_process() called [10:34:46]ACK! [10:34:46]Fuji cmd: GET SCAN RESULT [10:34:46]->SIO write 33 bytes [10:34:46]COMPLETE! [10:34:46] [10:34:46]CF: 70 fc 03 00 70 [10:34:46]sioFuji::sio_process() called [10:34:46]ACK! [10:34:46]Fuji cmd: GET SCAN RESULT [10:34:46]->SIO write 33 bytes [10:34:46]COMPLETE! Serial port closed! From here it looks like it's polling once a second to check for a connection and failing after 15 seconds when there isn't one. 15 seconds sounds like a long time to make a wifi connection to me but maybe it still needs longer? I don't know. I have over 20 devices on my network from Raspberry Pi's to laptops with TV's, phones and tablets in between and everything connects ok. I've got dual 2.4 and 5ghz connections and a guest network and I'v even split them into seperate SSID's so the fujinet can pick just the one it can use. It varies but the 2.4ghz SSID I'm trying to use has 4 bars on the fujinet config screen. The 5ghz one doesn't show up at all. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted August 4, 2020 Author Share Posted August 4, 2020 is your password being displayed properly when being typed? -Thom Quote Link to comment Share on other sites More sharing options...
jamm Posted August 4, 2020 Share Posted August 4, 2020 50 minutes ago, Mr Robot said: From here it looks like it's polling once a second to check for a connection and failing after 15 seconds when there isn't one. 15 seconds sounds like a long time to make a wifi connection to me but maybe it still needs longer? I don't know. I have over 20 devices on my network from Raspberry Pi's to laptops with TV's, phones and tablets in between and everything connects ok. I've got dual 2.4 and 5ghz connections and a guest network and I'v even split them into seperate SSID's so the fujinet can pick just the one it can use. It varies but the 2.4ghz SSID I'm trying to use has 4 bars on the fujinet config screen. The 5ghz one doesn't show up at all. For reasons unknown, there are times when the ESP32 seems to take an unusually long time to connect. I just ran a test where I cleared out my old configuration and tried reconnecting to my WiFi from scratch and had the same behavior you did. It does eventually connect, but not before the Atari CONFIG program gives up its status polling. It does seem to work fine after the initial connection, though - subsequent reboots of FujiNet don't seem to be a problem. It may have something to do with the proximity between a network scan and an attempt to connect. At any rate, try connecting again after the first failure. It worked in my case. In terms of the baud rate issue: I wonder if the Python-based firmware updater isn't slower than something like Visual Studio Code. i.e. It may be more of a software issue than hardware. If you're able to test with Visual Studio Code, I'd be interested to see the results. Quote Link to comment Share on other sites More sharing options...
jamm Posted August 4, 2020 Share Posted August 4, 2020 This is what normal behavior looks like when connecting to a network for the first time: 10:01:42.333 > CF: 70 fb 00 00 6c 10:01:42.334 > sioFuji::sio_process() called 10:01:42.334 > ACK! 10:01:42.334 > Fuji cmd: SET SSID 10:01:42.335 > <-SIO read 96 bytes 10:01:42.335 > ACK! 10:01:42.393 > Connecting to net: Justified password: xxxxxxxxxxxxxxxxxxxx 10:01:42.394 > WiFi connect attempt to SSID "Justified" 10:01:42.395 > esp_wifi_connect returned 0 10:01:42.396 > COMPLETE! 10:01:42.396 > 10:01:42.405 > CF: 70 fa 00 00 6b 10:01:42.406 > sioFuji::sio_process() called 10:01:42.406 > ACK! 10:01:42.406 > Fuji cmd: GET WIFI STATUS 10:01:42.408 > ->SIO write 1 bytes 10:01:42.408 > COMPLETE! 10:01:42.408 > 10:01:42.417 > CF: 70 fa 00 00 6b 10:01:42.417 > sioFuji::sio_process() called 10:01:42.417 > ACK! 10:01:42.417 > Fuji cmd: GET WIFI STATUS 10:01:42.431 > ->SIO write 1 bytes 10:01:42.431 > COMPLETE! 10:01:42.431 > WIFI_EVENT_STA_CONNECTED 10:01:42.739 > 10:01:43.469 > CF: 70 fa 00 00 6b 10:01:43.469 > sioFuji::sio_process() called 10:01:43.469 > ACK! 10:01:43.469 > Fuji cmd: GET WIFI STATUS 10:01:43.471 > ->SIO write 1 bytes 10:01:43.471 > COMPLETE! 10:01:43.471 > 10:01:43.487 > CF: 70 fa 00 00 6b 10:01:43.487 > sioFuji::sio_process() called 10:01:43.487 > ACK! 10:01:43.487 > Fuji cmd: GET WIFI STATUS 10:01:43.487 > ->SIO write 1 bytes 10:01:43.487 > COMPLETE! 10:01:43.487 > 10:01:44.537 > CF: 70 fa 00 00 6b 10:01:44.537 > sioFuji::sio_process() called 10:01:44.537 > ACK! 10:01:44.537 > Fuji cmd: GET WIFI STATUS 10:01:44.538 > ->SIO write 1 bytes 10:01:44.538 > COMPLETE! 10:01:44.538 > 10:01:44.547 > CF: 70 fa 00 00 6b 10:01:44.548 > sioFuji::sio_process() called 10:01:44.548 > ACK! 10:01:44.548 > Fuji cmd: GET WIFI STATUS 10:01:44.554 > ->SIO write 1 bytes 10:01:44.554 > COMPLETE! 10:01:44.554 > IP_EVENT_STA_GOT_IP 10:01:44.994 > Obtained IP address: 192.168.192.170 10:01:44.994 > Starting web server on port 80 10:01:44.996 > 10:01:45.604 > CF: 70 fa 00 00 6b 10:01:45.605 > sioFuji::sio_process() called 10:01:45.605 > ACK! 10:01:45.605 > Fuji cmd: GET WIFI STATUS 10:01:45.606 > ->SIO write 1 bytes 10:01:45.606 > COMPLETE! The important bits are "WIFI_EVENT_STA_CONNECTED" and "IP_EVENT_STA_GOT_IP". Those are notifications from the ESP32 that it was able to connect to the WiFi network and received a DCHP address. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.