BlueSCSI v2 - DaynaPORT WiFi!

[JDW]

Do you reckon I could reproduce this problem with a PowerBook 170 or 180?

I have neither of those models, so I cannot say if the Wake-from-Sleep freeze is exclusive to the Mac Portable or not, but you need only enable WIFI, confirm it works (connect to an FTP site, for example), then Sleep your PowerBook, wait 10 seconds, Wake it, then see if you can still use the machine normally. If you can, your machines are not affected by the problem.

 

[eric]

Does this happen with a real daynaport when you put the portable to sleep, unplug the daynaport, wake the portable, then re apply power to the daynaport? I'd venture to guess this might not be a scenario handled by the daynaport driver. But I have none of the mentioned items to test, so nothing to help.

 

[Androda]

I found this page with a bunch of pictures of SCSI to Ethernet solutions from a few providers:

SCSI to Ethernet Adapters (External) – Apple Rescue of Denver

applerescueofdenver.com

Every one of them has an external power adapter plug. And I think this may be the cause of the problem - an original SCSI to Ethernet adapter would not lose power when the system goes to sleep. That means it can retain configuration values in memory without issues.

BlueSCSI, on the other hand, does lose power when your system is put to sleep because it's treated as an internal hard drive which has no need for additional power while the system is sleeping. The Dayna drivers almost certainly expect the device to immediately pick up and resume responding, where BlueSCSI can't do that because all the context information stored in RAM would be lost due to the power removal.

One possible workaround (haven't tested it) would be to use an external enclosure with its own power supply connected to the BlueSCSI's floppy power input. This way your system can sleep but BlueSCSI does not lose power and thus can retain all the network context which was configured and can resume responding immediately when the system wakes.

 

[Mu0n]

Good to know. I just took a habit of externally powering my BlueSCSI which are external anyway, since it's available right there on my bench anyway. I wouldn't have repro'ed the sleep problem.

 

[JDW]

Does this happen with a real daynaport when you put the portable to sleep...

I actually didn't even know what a "real DaynaPort was." I Googled it just now. No, I don't have anything other than my Mac Portable (which is my only vintage Mac which sleeps) and the BlueSCSI v2 with PICO W.

BlueSCSI, on the other hand, does lose power when your system is put to sleep because it's treated as an internal hard drive which has no need for additional power while the system is sleeping.

One possible workaround (haven't tested it) would be to use an external enclosure with its own power supply connected to the BlueSCSI's floppy power input.

I appreciate that insight. The issue with that, of course, is that the intent here, in my case, is to replace the Conner HDD with a BlueSCSI v2. Which means, put the BSv2 inside the Macintosh Portable, into the drive bay. And it was for that reason I purchased the mounting bracket recently from you (which still is in transport to me).

I do know that the 5V rail of the Portable remains 5.28v while the Portable is in its wake or sleep state. I am not talking about power in that 34-pin SCSI cable the HDD. I am talking about the main 5V power rail. I always put my meter across the big axial cap nearest the heatsinked voltage regulator on the motherboard to watch it and see if it ever goes to zero. It doesn't. Wake or Sleep, it's 5.3v. So I am guessing that I could probably tap some point on that motherboard 5V voltage rail to keep BSv2 powered (which means the white "PWR" LED on BSv2 would then remain lit even during Sleep, which it does not do now). I've not tried that yet, because I'm not sure of the best point to tap. But realistically speaking, finding a solution for an INTERNAL BlueSCSI is prudent. Not sure how many people would want to attach and remove an external BlueSCSI to a Macintosh "Portable" each and every time they want to power on the machine. Too fiddly. Let's be honest.

I did a lot of testing last night, and I was even about to make a video for you all, but in the course of making my video, the Portable woke from sleep and didn't freeze, despite the fact the ACT LED had been flashing rapidly (a sign WIFI was active) at the time I put it to sleep via menu command. It freezes on wake most of the time, but due to the sheer magic of me filming, it decided not to freeze. It was at that point I ended my test for the evening and went to bed.

Again, I think we really do need to be realistic here and consider most Macintosh Portable owners probably will want to do as I am doing and have a BlueSCSI v2 "inside" their Portable, and not as an external. Sure, I might attach a BlueSCSI externally now and then, but I would never want that to be my only SCSI drive on the machine. To bothersome to connect and reconnect. As a result, whatever solution I decide upon would be to have the BlueSCSI kept inside the machine, in the HDD drive bay.

One obvious workaround is to never sleep the machine, ever. But compounding that problem is the fact I have the Portable Battery Eliminator. As we all have discussed before, there are reasons why that device does not provide a means for a 9V battery to be attached to keep the PRAM intact. And so, whenever I power my Portable, since I have no lead acid battery, I must use the Portable Battery Eliminator. And that means PRAM is reset. That means the Portable is set to auto-sleep in 2 minutes unless I manually go in and kill that feature. But of course, that gets reset again when I stop using the machine and yank the power cord from the wall socket. What I mean is, if ever there's a time I forget to kill auto-sleep, which will happen because there is no means of using a PRAM battery, there will be times the machine might Sleep when I temporarily walk away from the machine. And if WIFI had been active, there will be a lot of times it will freeze, which requires a hard reset. And that is why I am discussing this topic, to see how best to work around that freezing issue.

Thanks.

 

[Paolo B]

I have fabricated a hand made internal adapter for the Portable which feeds 12 V and 5 V for a standard full size molex connector. The pinout is available in the resource section of this forum. With SCSI2SD I had the same issue, the machine would crash upon waking up 99% of the times. With BlueSCSI v2 the issue was apparently gone. However, I must report that last time I took out of the closet the Portable for checking the “pop” issue, I experienced the system crash again. I will check if there’s any correlation to the status of the wi fi.

 

[Paolo B]

So, non lit Portable, 5 Mb ram, System 7.1.1.
BlueSCSI v2 Wi-Fi (on).
If I put it on sleep, it then crashes all the times.
By the way, the speaker pops, but just during the boot sequence.
If I boot from a floppy with System 6.0.7, I can put it on sleep and it wakes up flawlessly.
Will try and test some other configurations.

 

[JDW]

@Paolo B
Detailed testing feedback like yours, from fellow Macintosh Portable owners, is what I’ve been dying to hear. The reason is because when I alone report something, not much happens. But when more people confirm a given problem, ultimately there may be some light at the end of the tunnel igetting it resolved. So thank you very much for doing that testing and confirming the problem.

Because you have a custom-made cable, I would like to ask if your power source is supplying 5 V continually to your SD card drive. even during sleep?

In my case, the white “PWR” LED on BlueSCSIv2 turns off during sleep, and @Androda suggested that loss of 5v power in Sleep might be part of the problem. So that’s why I’m curious if your drive has been constantly powered during sleep.

 

[Paolo B]

@JDW My pleasure to help.

In the linked, impromptu video

I document the following facts:

- the 12V rail (and 5V, too) goes automatically alive during the boot phase
- when the machine is set on sleep, the voltage is shut off and remains off until the next attempt to access the internal SCSI drive
- booting from floppy with an empty BlueSCSI connected (as in the picture below), results into no sleep/wake up freeze
- booting from floppy with a loaded BlueSCSI connected, sleep/wake up results into a system crash
- booting from BlueSCSI System 7.1.1 sleep/wake up always results into a system crash

In sheer honesty, I kind of remember having this problem with my former SCSI2SD v5.0 unit and confirming that the issue was gone once swapped with the plain BluesSCSI v2.0. After upgrading to PicoWi I probably never spent sufficient time on the machine for noting that the issue is in fact still there.

As the MacPortable is back on my desk, I may run some extra test if needed.

 

[Androda]

Not sure how many people would want to attach and remove an external BlueSCSI to a Macintosh "Portable" each and every time they want to power on the machine. Too fiddly. Let's be honest.

Actually a great many people use the DB25 style specifically for this kind of usage. Plug it in when enjoying your vintage system, and unplug or put away when finished. Allows use of a single BlueSCSI across many systems.

And that is why I am discussing this topic, to see how best to work around that freezing issue

In terms of "how best to avoid the BlueSCSI turning off in a sleeping Portable", I recall something along those lines being discussed earlier in another thread: https://tinkerdifferent.com/threads/bluescsi-on-macintosh-portable.2764/post-23957

In this case, a 5v source was used that enables earlier in the post-sleep sequence and allowed BlueSCSI to work without freezing. But this is probably just another workaround that does something similar to the pull resistor modification you already did.

You *may* be able to force BlueSCSI to be "on" all the time in the following way:
* Run a jumper from the PDS slot Row A Pin 2 to the 5v pin on the BlueSCSI floppy power connector

PDS Row A Pin 2 is "VCC Always On", the same power rail used by the Power Manager chip. As indicated by the name, it's "always on" when the Portable has battery power.

 

[JDW]

You *may* be able to force BlueSCSI to be "on" all the time in the following way:
* Run a jumper from the PDS slot Row A Pin 2 to the 5v pin on the BlueSCSI floppy power connector

Thanks for the tip!
That won't be possible with my Forked BSv2 which doesn't have a separate power connector (instead, pulling it's power in the same exact way the stock 40MB Conner drive gets its power).



But @Paolo B could technically try that on his BSv2 because his is a normal one, as shown in his photo:

But just to re-confirm what you said... When using a normal BSv2 like @Paolo B has, you would connect only the 2 black ground wires in that 4-pin power connector (leave the 2 BLK wires but disconnect the YEL and RED wires), and then "Run a jumper from the PDS slot Row A Pin 2 to the 5v pin on the BlueSCSI floppy power connector." Meaning, like show below, correct?

 

[Androda]

booting from BlueSCSI System 7.1.1 sleep/wake up always results into a system crash

This is almost certainly because your BlueSCSI is an older hardware revision which is known to have issues waking from sleep. A fix is documented here: https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Hardware#hardware-tweaks--fixes

JDW has tested these changes on his Portable-specific fork PCB with success in resolving wake from sleep issues.

 

[Androda]

That won't be possible with my Forked BSv2 which doesn't have a separate power connector

A modification such as the below would probably work for your Portable-specific board. Take the voltage from PDS A2, pass it through a diode, and connect to the side of C16 as shown. No additional grounding should be necessary, just this one connection.

Though I suggest checking with the person that modified the PCB design to ensure that connection on the right-hand side of C16 is the correct place for main power input. I'm just guessing based on what I know about the older BlueSCSI V2 hardware design.

 

[Paolo B]

This is almost certainly because your BlueSCSI is an older hardware revision which is known to have issues waking from sleep. A fix is documented here: https://github.com/BlueSCSI/BlueSCSI-v2/wiki/Hardware#hardware-tweaks--fixes

JDW has tested these changes on his Portable-specific fork PCB with success in resolving wake from sleep issues.

Good to know, thanks, I will surely try this fix.

 

[JDW]

Take the voltage from PDS A2, pass it through a diode, and connect to the side of C16 as shown. No additional grounding should be necessary, just this one connection... Though I suggest checking with the person that modified the PCB design to ensure that connection on the right-hand side of C16 is the correct place for main power input. I'm just guessing based on what I know about the older BlueSCSI V2 hardware design.

Yes, capacitor C16 is on the main 5v rail on my forked BSv2 board, as shown below.
I will give your diode-isolated jumper a try this evening. Thanks!

 

[JDW]

@Androda
I just tested the diode-isolated connection between PDS-A2 and the positive side of C16. It works! Every time I sleep the machine with WIFI active (ACT LED flashing rapidly), the machine sleeps, but PWR remains lit (ACT no long blinks), and then when I press any key the machine wakes and the ACT LED begins to flash rapidly again. I can then go back to using WIFI to browse the web, etc.

Also, I used a regular silicon diode, not a Schottky like D2. The normal voltage level without my jumper attached is about 4.91v when measured at C16. When I connect my jumper and sleep the machine, the voltage is 4.4v due to the larger Vf of the silicon diode. Even so, that lower 4.4v still keeps the BlueSCSIv2 alive such that the machine wakes without freezing. Another advantage of using a larger Vf diode than D2 is that when the machine is powered, all the current will be channeled through D2, not my silicon diode. But maybe that doesn't matter.

The main downside to this jumper fix, of course, is that if your little jumper wire ever slips out of the PDS socket and hangs free inside the machine, that's a male pin that could short on something. And since the other end of that jumper is tied to C16, you'd have a live 5V wire to worry about possibly shorting to ground.

A second downside is that BSv2 will remain powered even after Shutdown. I usually shutdown the Portable before I remove the SD card so I can manipulate files on my modern Mac. Not sure if its good to remove the SD card with BSv2 fully powered (PWR LED lit). Thoughts?

But if you ignore the downsides, the end result is great. No more freeze on Wake due to WIFI!

 

[Androda]

I usually shutdown the Portable before I remove the SD card so I can manipulate files on my modern Mac. Not sure if its good to remove the SD card with BSv2 fully powered (PWR LED lit). Thoughts?

With the Portable fully "turned off" there should be no SD card access going on. It should be relatively safe to pull the SD card and manipulate files / images in this scenario because there's no drive activity.

 

[Paolo B]

Maybe I’m missing something, but the proposed mods to the board have kind of bricked the unit, which is no longer recognized during the boot phase. Firmware successfully updated to the latest release, LOG.TXT reading all checks OK.
D3 flashes for a while during the boot step, but then nothing happens and it just hangs.
R23 removed, 4.7k Ohm resistors from the capacitors C13 and C9 (connector side) to respectively pin 5 and 12, counting (in the picture) from top left corner of the Pico (no shorts with the leads, they are well detached from the other components).

 

[Androda]

Maybe I’m missing something, but the proposed mods to the board have kind of bricked the unit, which is no longer recognized during the boot phase. Firmware successfully updated to the latest release, LOG.TXT reading all checks OK.

That's really quite strange.

I just modified one of my units based on the instructions here and it boots right up on my Portable. Tested sleep, and that works too. It's even a 2022.12a like yours. Don't have much to go on for why this wouldn't work properly.

 

[Paolo B]

Good to know you you have evidence the mods work fine. I will check it thoroughly again, including the scsi cable, maybe some contact in the connector got loose with all the push and pull…