xssfox

This is the story on how I spent far too much money and time getting a scanner to work over iSCSI so that I could prove “Chris O” wrong on StackExchange. The TL;DR is that yes scanners work fine over iSCSI.

It begins with waking up to the thought “could I connect a scanner to SCSI disk array chassis” - probably after watching too much Adrian’s Digital Basement. I think this this is very much possible, but the thought morphed into - what about iSCSI arrays. While I joked about it I put off further investigation when I saw the price for iSCSI bays. They are still stupid expensive.

The idea still stuck with me though and I wanted to do some more research into if anyone had. I didn’t find much. All I really found was Chris saying it couldn’t be done because:

iSCSI isn’t a complete encapsulation of the SCSI protocol over TCP/IP. … Source: 15 years of managing iSCSI storage networks.

This bugged me a lot because it didn’t point to any sources. I decided to read through iSCSI RFCs and couldn’t find anything that would suggest that it wouldn’t work. I suspect Chris hasn’t had as much experience managing iSCSI scanner networks. Being theoretically correct is one thing though - I wanted to be practically correct.

The Setup

A minimal test setup requires three things:

• iSCSI Target (this is a server for normal people)
• iSCSI Initiator (this is the client for normal people)
• A SCSI scanner

Turns out that even though iSCSI arrays are still expensive tgt (iSCSI Target software) on Linux supports passthrough devices.

So our setup ends up being:

• Linux tgt iSCSI Target
• Virtual machine on a different computer iSCSI initiator
• A SCSI scanner

With the discovery of tgt I thought this project would be simple, however a reoccurring theme with this project is that the simple things end up being the hardest. The first problem is that inexpensive scanners only existed in my head. Turns out most scanners sold 2nd hand today either don’t have SCSI or are pricey. Eventually I came across a Canoscan FS4000US film scanner for a reasonable price.

The reason it was a reasonable price is that the slide/film mounts were missing. This most certainly wouldn’t be a problem as I don’t need to actually scan film (she thought).

Drivers

There’s a bit of a meme about printers being the worst computer accessory to setup, configure and maintain. I don’t believe this is true. Scanners a far far far worse - this is why you don’t see scanners today - we lost. The FS4000US was released to market sometime around 2001 and 2002 from my research. It received 32bit drivers up to Vista.

My first task was to test the scanner on USB to ensure it worked prior to iSCSI fun. Luckily VueScan still exists and provides a driver replacement for the FS4000US. It was able to detect the scanner. Great win!

A slippery slide

VueScan however would not let me scan as it couldn’t detect the slide/carriage for the media being inserted. When I purchased the scanner I knew the slide was missing. I was hoping that it would just scan without checking, and if it did check it would just need a limit switch locked down. This was not the case - the FS4000US has a loading mechanism (it’s actually fairly complex) and uses a light sensor to perform alignment.

After many attempts to “trick” the sensor I started designing a 3d printed slide replacement however before kicking off a print I decided I’d try “one more time”. I managed to trick the sensor into thinking film was loaded and VueScan happily scanned an image!

Other parts SCSI or SSCCSSII

It’s time to talk about SCSI. The FS4000US is “SCSI-2”, which at the time was the latest specification for the SCSI standard. Confusingly SCSI-2 refers to two different specifications - Wide and Narrow. Wide came about in 2003, while Narrow came out in 1994. As such the FS4000US is Narrow SCSI. The best way to think of narrow and wide is that they double the bus width - more pins. Because of the additional bus width the number of devices on the SCSI bus changed from 8 to 16.

There’s some other considerations with SCSI as well - SE/HVD (Single ended / high voltage differential) or LVD (low voltage differential). Along with clock speed. The FS4000US is narrow, 10MHz, SE/HVD. Modern SCSI is wide, 160MHz, LVD.

The good news is that most SCSI devices are backwards compatible (usually sacrificing speed on the bus). The only important consideration is usually LVD vs SE/HVD. I hunted down a PCIe SCSI card and ended up with a Dell LSI20320IE. This has an internal SE/HVD connector.

Oh connectors. Connectors. I mentioned the difference between wide and narrow, but here’s where it gets fun. Our FS4000US has a HD50 connector (50 pins) - this is usually a little bit unique but not unheard of. The LSI20320IE has a HD68 connector (68 pins). So how do we connect a narrow device to a wide controller? We buy a dubious cable.

I ended up with this HD68 to HD50 cable. I’m pretty certain this is designed for when your connecting a newer hard drive to an older controller. Why would this matter though?

Well as SCSI is a bus you end up with long cables with many devices sharing the cabling. As there’s no dedicated device at the start or end of the bus the signal would reflect off the end of the cable. This is why we have SCSI terminators. Often these are built into devices and as long as you set the terminator on the first and last device everything is fine. Other times you might use dedicated terminators plugged into the cable. These terminators prevent signal reflections and make the bus stable.

Bringing this back to the cable, we have 68 pins on our wide side and 50 pins on the narrow. This means there’s a bunch of pins that are left unterminated. This originally concerned me, but on my very simple SCSI configuration I realised that this would likely be fine. This is because the cable likely only contains 50 pins and the SCSI card itself will be acting as the first terminator - there should be no reflections at this point. On a complex bus with multiple devices this could be a problem though.

I did look into proper 68 to 50 adapters however these are either very expensive or just not available. I guess their usage was fairly rare to start with.

Anyway, my HD68 to HD50 cable worked just. Lol just joking. Once again the simple things end up being the hardest. I bought an external cable, but the SCSI controller card has the HD68 connector on the inside of the card. It physically wouldn’t fit. So I took to the cable with a Stanley knife and cutters. Eventually it fit.

Unit testing

It’s usually best to test each part of a complex system individually. My plan was to connect the scanner with SCSI on my Windows machine and do a scan. This was to test that SCSI scanning worked locally before moving to iSCSI.

I downloaded the latest drivers I could find for the SCSI card and promptly got a green screen of death. Followed by boot looping Windows. The driver installed the 32bit driver on a 64bit system. Windows was not happy. The simple things.

I tried some 64bit drivers. This installed ok, no boot loop however I got a This device cannot find enough free resources that it can use. error. I never worked out what was happening here.

Fine. I rebooted into Linux. It could see the controller and the scanner - huge win. But no one ever wrote Linux Xane drivers for this scanner. Fine I thought - I would run a Windows VM, pass through the PCIe device and run a supported Windows Server 2008R2 setup. Turns out in version 7 for VirtualBox they removed PCI passthrough. I’ll try virt-manager.

Virt-manager approach saw seabios hang on boot. I tried to get uEFI working but my Linux build was too old to have the required files. Do I even need to passthrough the entire PCIe device though? Maybe I just pass through the SCSI device. virt-manager GUI however didn’t show a way to passthrough the devices so I learnt how to build the XML myself. Start the VM and get permission denied. Turns out apparmour was unhappy about it. Fixed up apparmour only to find Windows Server build didn’t have drivers for the virtual SCSI controller. Arghhhhhhhhh. Lets give up with this.

Yolo

Someone in a forum helpfully suggested that rather than using virt-manager for SCSI passthrough just use iSCSI. So lets just do that (sans virt-manager). It shows up on the bus. It’ll be fine right?

On my Linux host I started tgt service and configured the passthrough device. There’s some helpful documentation here. It comes down to these commands

tgtadm --lld iscsi --op new --mode target --tid 1 \
-T iqn.2001-04.com.example:test

tgtadm --lld iscsi --op new --mode logicalunit \
--tid 1 --lun 1 --bstype=sg --device-type=pt -b /dev/sg1
	
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

That’s it. The part I thought would cause me the most grief worked just fine.

Operating system woes

I decided that I wanted to use my laptop to connect to the iSCSI target. MacOS doesn’t have native iSCSI, so I decided I would run a virtual machine. Fired up Windows 11 in parallels however it seems like iSCSI has been completely removed in Windows 11. Maybe it’s the ARM build I have? It’s the simple things once again.

So I build a Windows 7 VM in UTM. Setup iSCSI Initiator. Excitement as the scanner shows up in device manager. Install VueScan and go to scan. Unlike before I can’t seem to do the magic to make the scanner happy about being loaded. Turns out the logic for checking that there is something loaded into the scanner is performed in software. I suspect that VueScan implements this logic different between SCSI and USB versions? Simple things.

Scanning

After a lot of messing around I eventually built a Windows XP VM along with downloading some sketchy DLL files. Wildestdreams has some third party software to run the scanner over SCSI. It doesn’t implement any media checking so will happily scan without being loaded!

With that I was able to perform a scan over iSCSI. Of course the scan quality is rubbish because I’m not using film, the slide and haven’t calibrated the gain for each channel but the point remains it scans over iSCSI. Chris O - you’re wrong!

I did try the original Canon Twain driver - I think with the correct slide/tray it would work fine. It’s just very picky about the loading.

The original dream

The original dream was having a bunch of flat bed scanners connected to a disk array enclosures. While I can’t afford to see it happen, this experiment gives me hope. There’s no guarantee that it’ll work though as who knows what those iSCSI controllers are doing.

We drive long distances in remote places. Sometimes we want people to be able to check-in on us while we are out and about. While cell coverage is getting better we still often find ourselves in places with no coverage.

Often we leave our HF radio tuned to a known frequency (usually 7045 kHz LSB) while we are driving and have VSC or power level squelch enabled. However this has false triggers. When driving through towns there is usually a lot of RF noise and even when we aren’t there’s noise from our car, other HF radios, or even just ionsondes or CW operators.

Random noises while driving are very frustrating. In the commercial space radios are fitted with selective calling (Selcall) functionality. This allows one radio to call another radio provided you know the ID number of the other radio.

The great thing about standards is that there are so many to chose from - Selcall being no exception. While there are many different Selcall variations today we are going to talk about the Codan specific Selcall - specifically the not the CCIR / UN / WA2 / RDD / Customs variants. Nor aircraft SelCal. The proprietary Codan “standard” is what we want to look at. The reason behind this is that there are numerous Selcall users on 7045kHz already using Codan Selcall and while it’s proprietary we can still interoperate with those users.

Modulating

The actual Codan Selcall process is actually pretty well documented with VK5QI already creating an open modulator including some of the less documented features such as channel test modes.

I decided to use freedvtnc2 as a skeleton project as it already has an FSK modem (Codec2), audio and rigctl components. From there I implemented the Selcall protocol while testing and researching some of the extra modes from our Codan 9323. Modulating a Selcall signal was now trivial - but we already knew and had that. What we really wanted was an opensource decoder. Something that could detect Selcalls.

Demodulating

Demodulating is a little bit harder, but given that we know what the signal looks like and Codec2 provides a good FSK demodulator it was not outside my skill level.

Codan Selcalls start with a preamble, usually quite long to allow radios scanning channels enough time to detect the signal. To an extent we can ignore the preamble as the Codec2 modem will handle locking onto the signal for us.

After the preamble there is a phasing pattern. This is a header that is at the start of every Codan Selcall. It’s nearly as simple as looking for this pattern to determine when a Selcall has started. But you don’t want to do an exact match as in HF radio its likely that noise has caused some bits to flip. I settled for a 85% threshold, however I think it could be even lower in practice.

Once the phasing pattern is found it’s matter of decoding the bits as they come in. There’s a few fun things in here. Codan uses a 7 bit word and 3 bits of parity, so you have to handle the incoming data as a series of bits rather than your typical bytes. Parity is only at the word level. There is no checksum on the entire message. The data is effectively sent twice (offset) so if parity fails on one word you might be able to recover it from the other.

The parity is a count of the number of 0’s in the word.

For my demodulator it works like this:

• Store a rolling buffer long enough to fit a Selcall
• Look for phasing pattern
• If a phasing pattern is found try to decode each field - check parity - use the redundant field if required and available

Fun fact - if you are really unlucky both copies of a field could return a successful parity check but have different data - as there is no overall checksum for the message you won’t know which one is correct. When receiving a Selcall we just check if either field is our Selcall ID.

So you decoded a Selcall - what now?

Decoding the Selcall is only part of the process. We need a way of alerting the user that there’s a call for them. It would be really really really nice if ICOM allowed user defined messages (more on this later) and activating a beeper - but in the meantime lets aim for something simple. Rigctl.

When we send a Selcall we actually need to control the rig - turn the radio to data mode, trigger ptt, return the radio to voice mode. Since we already have rigctl for that, how about we use it for alerting the use as well.

The simplest solution I thought of is using the squelch adjust. On our rig you can configure the USB audio output to remain active even when the radio is squelched on the head unit. So the flow looks like this now.

1. Squelch the radio to a fairly high level - unlikely to get false triggers
2. Software listens for the Selcall
3. When it receives a Selcall for our configured ID number use rigctl to unsquelch the radio
4. (additionally) if the Selcall requested the channel test mode and the option is enabled send back a test signal

Freeselcall

I built all of this over a couple of days and have called it freeselcall. It’s had some over the air tests - but I wouldn’t say it’s battle hardened.

I realised that most people, myself included, wouldn’t want to use a terminal to perform selcalls so I’ve also added a web interface. It uses websockets so it should be easy to integrate with other systems as well.

More than just Selcall

Freeselcall allows for sending and receiving Selcalls with various priority types along with the option for channel tests. However Codan radios can do more. They can do paging (short messages).

Today freeselcall can receive pages. It also has code to send pages however Codan decided to add some security words to process. As it stands a Codan radio will not receive the page messages from freeselcall.

I’ve spent a lot of time in Ghidra along with building a Codan 9323 emulator (it can display the LCD boot up message!) to help reverse engineer how these security bytes work. Hopefully in part 2 I can share how the paging messages work. Emulating a unique flavour of 8051 along with the hardware it connects to has been fun.

The future (and a terrible idea)

As I alluded to earlier - being able to display a message on our ICOM 7100 would be ideal. However there’s no rigctl or CI-V way of displaying a message on the 7100. Or so I thought. It was only when I was dialing in a repeater on the 7100 that I came across an idea that might work. I haven’t tested this, but here’s the plan.

1. Dedicate a memory channel for freeselcall.
2. When a call comes, if the radio is in memory mode, store what memory the radio is in.
3. Use CI-V command to save the current radio state as a memory in the predefined freeselcall memory channel overwriting any existing configuration in that slot.
4. Update the channel name with the message / selcall id / ect….
5. Tell the radio to load that memory
6. After some time has passed and the radio hasn’t PTT’d in awhile, either restore the radio to the memory it was set to or turn off memory mode

I think this will work? But I have no idea until I try

The other addition I want to add is either implementing more sensible Selcall protocols or building a more modern robust one. This can run in parallel for backwards compatibility.

I haven’t even looked into 6 digit pagecall. I haven’t seen it used on amateur bands so I’m not overly interested.

A final note….

Part 2 won’t be coming out until I’ve either been able to emulate the Codan firmware (just because thats cool in its own right) or I’ve been able to figure out the magic for the secret words. The emulator is at the point where I need to have the base and the head unit emulated at the same time and talk via the I2C bus. This shouldn’t be hard, however it’s also not something that is trivial.

Please do not send me yet another a copy of the Codan CCIR 493-4 PDF. This afaik doesn’t contain any information on the secret words and I have enough copies of it from people being helpful.

JSON’s had a tough life. Before I was all that attached with the bike I didn’t exactly treat it with same the respect I do today. It was just a cheap bike to get me from point A to point B. The more I rode it the more I fell in love with it. Combined with damage from the previous owner and other general wear and tear the frame was starting to show some signs of rusting.

The plan was to strip the bike of paint, then respray it. This wasn’t going to happen in our apartment, however an excuse to visit Mark in Adelaide presented itself. I took the bike across the border and over the period of several weeks redid the paint work.

Prep

At this point I’d become pretty familiar with the process of removing every type of bike part on my bike. Within a few hours I had removed everything which left only the frame. If you are planning on embarking on this adventure and you are unfamiliar with removal of all your parts, get some help or do some research. Some parts can be fragile, some have reverse threads and some can be damaged if force is applied in the wrong spots. There’s also a bunch of tricks to learn for when things don’t go to plan.

An example is the quill stem - often on these bikes they become stuck. If you try to strike the stem directly you’ll likely either damage it or get it more stuck. While it doesn’t always work a good starting place is to leave the stem bolt in, but proud, then strike the bolt with a hammer - this will dislodge the wedge and hopefully allow removal of the stem.

After removing all the parts from the bike frame I decided to strip most of the paint off the bike. Now stripping the paint entirely off isn’t necessary. You only need to strip the paint back far enough for the new paint to stick, along with getting the surface finish to the quality you want it. I went for stripping it back entirely (there were a few bits I couldn’t easily get to so I just roughed these up as best I could). The reasoning for stripping back entirely was to ensure there was no hidden rust - along with removing a nasty paint run was present on the bike already.

I’m really glad I did strip it all the way back during sanding I noticed some weird pattens forming, slowed down an used a higher grit sand paper. To my surprise the red and white paint scheme wasn’t original. I had suspected this given the paint run, however I could never confirm this. I never knew the make or model of the bike and by carefully sanding back the top layer it revealed a uv damaged outline of the original branding. An Apollo Eclipse. This would have been the pink and white model. For me the bike has always been red and white, that’s now part of its history. So while I could return it to original colours, they wouldn’t be original to me.

For the majority of stripping I used low grit sand paper however for the fiddly bits I restorted to wire wheel brushes on a cordless drill. Removing the paint is probably the hardest part, once its removed moving up in grit to make a smooth finish happens fairly easily. I went with the sanding approach because sand blasting seemed too expensive for this project and sanding didn’t seem like too much effort (it was a lot of work, don’t get me wrong, but it didn’t really take that long). I looked into chemical processes however youtube tutorials and reviews gave me the impression that it seemed more annoying than just sanding. Everyone has different advice on the process however I settled for about about 400 grit for the final sand working off the theory that while spray paint is thin, it still needs some roughness to the surface to stick well. I used higher grit sandpaper to touch up some parts during painting. If you want to take away anything from this blog post though, think PPE. Not just when spraying paint but when sanding. I generated so much dust when sanding back the frame.

Painting Rust

The next day with all the rust and paint sanded back I went to paint. I thought I’d be able to get away with a day of stripped bike frame in less than 20% humidity but flash rust struck. It wasn’t a big deal however, I was able to sand back the frame with high grit sandpaper again just prior to painting. I gave the frame a wipe down with some acetone to remove debris and now we were ready to paint.

Painting

I went with Rust-oleum 2X Primer and Custom Spray 5-in-1 for the paint. This was mostly because I’m familiar with how they spray and work. They probably aren’t the best choice for bike paint, however rattle cans in general aren’t good - this is because the layer of paint is so thin compared to other methods. Regardless it’s something that fit the budget, and that I could easily do.

I actually reached out to Rust-oleum to confirm my planned process prior to painting and they were able to provide a bunch of nice details and provide confidence. First up was priming. The Rust-oleum paints allow re-coat anytime within 1 hour and they recommend coats 15 minutes apart. I setup the forks and main frame near each other so I could do them at the same time. This allowed me to switch between each while waiting. I was able to get 4 coats onto each within the window. The usual rattle can advice applies - thin coats. Sicne the frame is so large I applied thin coats and moved around the frame, usually doing 3 coverages every time I did a coat. Priming was probably the hardest part not to get runs on I got a slight run during this and sanded it back prior to the top coats.

Since the bike was lacking any sort of branding, I wanted to give it some. I had a original plan for that - Crossy JSON - however since I now knew the make, model and what the original decals looked like I incorporated some of the design into my plans. There was the option of simply making some decals and slapping it onto the bike afterwards, but I really wanted to try using the decals as mask. I cut out some new decals for a mask and applied them careful. This meant that prior to the decals being applied I had to do some extra top coats in the masked off colour.

Some red coats went on. The Custom 5-in-1 cans low output mode really helped prevent any runs. I got a slight run where the rear brake sits but it was easily fixed up. The tricky part however was replicating the “original” white gradient on the dropouts. I did a few practice sprays for this to get an idea of what I was doing along with masking off everything that wouldn’t be part of the gradient and in the end it turned out great - I feel like its better than the previous gradient.

The masked off sections were removed prior to the clear coat. This is where I learnt that my masking approach was probably wrong. A negative mask would have been easier to remove (I created a bunch of damage to the paint getting each piece off) and would have made the painting process easier. Regardless I’m happy with the results given it was my first time doing this sort of thing.

I was originally concerned about runs on the clear coat - because that could have caused disaster, however even on high output mode I couldn’t have made a run if I wanted to. I’m sure the temperature helped but I feel like the chemical composition just makes it really hard to run with that paint. One approach for painting bikes it to actually not worry about clear coats, just make the top coat as thick as possible. I however wanted the finish that the clear coat provided.

Post

Prior to reassembling the bike I decided to give its internals a blast of cavity wax. This is intended to prevent rust from the inside. An idea I picked up from Croker vs ROVER. Most of the internals have drainage holes that the applicator can be fed through.

Pre-sequel

During painting I throughly washed all the parts, rebuilt bearings and placed everything in Evaporust. The Evaporust worked a treat, however flash rust struck again leaving me to have to repeat the process for many parts. The problem is that with the rust removed, washing with water just creates the perfect surface for more rust. I think the solution to this varies per part, varying from an aciditic bath, zinc plating and painting. However for the time being I went with a light coating of WD-40 (which is apparently the original purpose of WD-40). I think if I do this again I’ll have a think about how I deal with this.

I also found that many parts on my bike were broken. I ordered a replacement seat as the plastic holding it together had cracked. A spoke was broken on one of the wheels. The new spokes that I ordered were too long (they must of been the perfect size before, as the new ones were less than 2mm longer than the old) so I’ve reconfigured the wheel for a 4 cross spoke pattern.

The chain, bell, and cabling were all replaced. Along with the handlebar tape.

Finally

While the bike is mostly done now I still need to true the wheels a little better, along with draw up some of the spoke tension. I’m pretty happy with the results. There’s some bits that I messed up or could do better but for my first attempt I think I did well. It’s certainly better than when I started which is the key thing.