I really feel unqualified to continue to comment, and hope that someone will chime in who has some experience with an SDR... for what it's worth, here's more wild speculation from my vast imaginary world
Speculate away I'm just extremely grateful for any input and very much appreciate you taking the time
I don't "really" know what that $SDR$$.$$$ file is all about, but if we're dealing with "Dynamic Firmware" that gets loaded into the chip on every boot, then that data would need to be stored somewhere, while the unit is off. So, it could be that.
I'm really not sure how it works either if I'm honest, its just educated guess work but you seem to have much more working experience of these things than I do so any idea could actually crack this, it's all worth a try.
But I'm lead to believe that the $SDR$$.$$$ file is what would be on the Harddrive on production and the operating system which is stored on the EEPROM reads it when the Harddrive boots up and as it's missing from mine nothing can happen and the file was never release by Mackie, the only stuff they released where the continuing updates over time as extra operation modes where introduced, apparently the SDR was originally released for sale with only half capabilities in operation and they introduced the others over time.
So, my guess would be, that the SDR writes the content of the EEPROM to that $SDR$$.$$$ file (after it successfully booted once - USB mode wouldn't count, I'd think), so it knows that it successfully booted off of that before, and can load it back in, if it needs to. Either on every boot, or possibly it could be a firmware backup, that it looks for when the battery fails, and the firmware data was lost on power-down . (in case it loads the firmware into the EEPROM once and keeps it there after shutdown, via the battery).
So, if that was the case, then it's possible that the SDR.FW file and the $SDR$$.$$$ file have the same content. But possibly in a different format (or the SDR.FW file could have some sort of extraction app in it, that reads the data from a different section of the file, and writes it to the chip - so, maybe not a straight 1:1 copy process).
I think ( and I'm only guessing ) your understanding in the last part of the top paragraph is correct the initial programme is permanently stored In the EEPROM and reads the updates from the hard drive, so if the hard drive failed the system can be recovered by putting the SDR into flash recover mode.
But I would have thought that would make the EEPROM write the initial software back to the Harddrive, but I'm not Software / Firmware savvy so I'm only guessing.
Also I thought EEPROMs didnt need a battery back up as whatever is written to it is committed to a non volitile memory? is that correct?
Do both files happen to have the same file-size? If not, then they're probably either for a different purpose, or in a different format (or one includes that extraction app or something).
Both of the SDRREC.FW (227KB) and SDRSTD.FW (392KB) files are different sizes but I have no idea what size the $SDR$$.$$$ file is or even what it is?! In fact it could be just a generic symbol representation of what should actually be there whereas the $ is actually a substitute for a number or a letter of some sort.
What I'd try (but there's a bit of a risk, in case the EEPROM can't handle it and might need to be replaced or re-flashed afterwards), would be to rename the SDR.FW file to $SDR$$.$$$, then reboot, and see what happens (if you're willing to risk bricking the EEPROM).
Funny you should say that I did try that idea and renamed the SDR.FW file but it didn't do anything as far as I can tell I don't think it bricked the EEPROM I think it just didn't read it because it didn't mean anything to the EEPROM
If you have an Editor that is used for development (e.g. BBEdit on the Mac... that's free. Not sure if that, or something like that also exists on PC), then I'd try to open it with that, and compare what's going on inside the files. (Or just try Textedit first... sometimes these files are simple text files).
That's an area of editing these kind of files that I've never ever got into I wouldn't know what I was doing I would be starting from scratch and would have to educate myself on the whole process, so that could be something for later down the road but I'm going to remember what you posted here and look into it.
Stupid question, though (...my tech support past taught me to always ask this stuff, no matter how ridiculous, sorry...) the USB cable is DEtached from the SDR when booting, right? I could imagine that it boots straight to USB, whenever a cable is plugged into the USB port.
If the USB cable isn't connected, and renaming the file doesn't help, then I really don't know what it could be, and should refrain from responding again.
An excellent and much overlooked point, in fact it doesn't matter whether the USB cable is plugged in or not, the machine defaults to the USB mass storage mode on switch on whether the cable is attached to a laptop or not.
Maybe someone on here would at least be kind enough to send you their $SDR$$.$$$ file, so you can put it on your drive. Maybe it would actually boot from that, if that IS a firmware backup. Then it would still point to the battery not helping to hold the firmware in the chip, though.
Yes I'm hoping someone has the file that I can get from them and give it a whirl that way
Where are you measuring that the battery supplies power to the board? Or to ask the other way around... I'd think that if you just hold the pins of a multi-meter to the positive & negative posts from your battery holder, then you'd get a reading, no matter if power is actually supplied to where it's needed. So, I'd follow the traces on the board, to see to what component it goes, and then measure on the pins that connect to that component, to see if voltage is still present. Having said that, though - I'm terrible with electronics, and have heard before that you can fry something, just by measuring with a multimeter in the wrong spot on a board. So... please try at your own risk... or ask someone who has a clue what to do or not to do with electronics before trying that.
In fact a friend of mine who fixes valve amps for hi-fi enthusiasts came over with his multimeter and measured it for me, he measured the battery socket to see if power was getting through to the two contacts and then he measured the battery further along the traces on the circuit board to where they connected to the next component in the chain, and he told me he was getting a reading of 2.6 V from a fresh battery
Sorry... I think that's all I can contribute to this, since I just don't know the SDR at all (I understand that it's non-PC hardware and that there's likely no PC-style BIOS, etc. - but that doesn't really help with figuring out what might be wrong, sorry!)
Again, best of luck! Hopefully you'll get it working!
You're correct about there being no BIOS so it doesn't operate like a PC in any way as I may have mentioned in a previous post this was actually created by a completely different team that did the HDR or the MDR and the D8B quite awhile after those three units were introduced onto the market.
You've been absolutely brilliant in taking so much time and effort to give me your ideas about how to chase down the issues with this SDR and you've given me many ideas for continuing so a big thank you for that.
I think my next two options would be either to get hold of another one of these in a non-working condition but also hope that some kind soul that already has an SDR would be willing to help me with a copy of what ever operating system they have on their hard drive, i've had this SDR in this condition for five years so if nothing else I'm tenacious and with the age of this Mackie gear being tenacious is an advantage, I'll keep going with it, thanks again my friend , your time is very much appreciated.
