Well here we are in 2020, remote work is finally here and after decades of marketing by every major telecommunication company, my mum knows how to make a video call. Unfortunately this sudden enthusiasm caused unprecedented shortages of webcams. We can't let this slow us down as there are important calls to be made and I have the solution. Introducing the Mitsubishi VisiTel!
Saturday, September 19, 2020
It has taken almost 30 years and a global pandemic, but we finally have accepted the inevitable fact that we are going to have to take a shower before talking to our colleagues on the phone. Video telephony is here in force.
I am not the first person to think there is something specially kitsch about the VisiTel. People have been tinkering around with these for a while and despite not having motion video, it is one of those products which was clearly a feat of engineering and massively ahead of its time.
Japhy Riddle's video is what got me really interested in the VisiTel. He pointed out that by slowing down or speeding up the recording of an image sent to the VisiTel the image skewed on the screen. Immediately I knew this meant the device used a simple AM modulation scheme. With that knowledge in hand, I jumped on eBay and picked up a unit to play with. My goal: to make this glorious time capsule of late 80s tech work with 2020's work from home platform of choice, Zoom, so I can chat with my colleagues. Moreover I want to do this without modifying the hardware because these things are just too cool to butcher.
Step 1: Electrical interfacing
The VisiTel is extremely easy to set up. On the back of the device is one long cable with a Y joint near the end (more on this in a minute) and two plugs. One plug is a 2.1mm DC barrel jack with which the device is powered. It expects 15 volts center positive. Oddly they chose to write the number 15 on the device in a font that makes it appear to read "IS Voltage". The second plug is an RJ11 connector with two of the pins populated. This is the standard layout for a telephone handset. If you remember corded phones you might also remember that the receiver was connected to the dialy bit (technical term) by means of an RJ9 connector and the dialer to the wall with an RJ11 connecter. The intent being that you could plug other accessories into your dialer, or replace the receiver | cable if something went wrong. Not that the latter problem would happen often because telephone handsets used a special kind of wire which is extra flexy.
Returning to the back of the VisiTel, along with the cable there is also a RJ11 socket. After scratching my head for a while the obvious dawned on me. The VisiTel is designed to man in the middle your telephone so that it can listen or transmit whilst you make calls. That leads to an obvious problem, as the VisiTel unit is sharing the wiring in parallel with the telephone the user is going to hear images being received and transmitted. Well the engineers at Mitsubishi thought of that and whenever you receive an image or transmit one there is a loud click from the device as a relay disconnects the handset. For our application we aren't interested in listening to the audio signal, so we aren't going to plug anything into that RJ11 socket on the back of the device. This makes the isolation relay superfluous meaning it could be removed for clickless image sending.
So how do we communicate with this device? My computer for one doesn't have an RJ11 socket on it.
No worries, apparently there is a market for adaptors to connect your RJ9 telephone handsets to smartphones. Or you can simply snip off the RJ11 connector and solder on a mono 3.5mm jack. Note: I originally thought the VisiTel had an RJ9 connector not an RJ11.
With your 3.5mm jack in place connecting couldn't be simpler. Get a USB sound adaptor with separate microphone and headphone output jacks (not TRRS) and plug the VisiTel into the appropriate socket.
I said that I'd get back to the Y joint on that cable. On my device the wires in that joint had failed, not a nice solid "it's broken" failure, but one of those nasty types of failure where everything works when you go to bed and the next morning it doesn't. If only the VisiTel team had used some of that special extra flexible wire. This intermittent failure cost me days of staring blankly at screens, fruitlessly looking for thermal issues, and triple checking my sound card settings. Eventually I discovered the failure when in frustration I picked the device up during a test and saw a crackle of static on my recording. If there is a lesson about old hardware to be learned here it might be to perform a "jostle" test once you have everything working and see if anything suddenly doesn't.
Step 2: Understand the protocol
As you can see above I wanted to validate my understanding of how data was encoded, so I sent some very simple sample images from the VisiTel. These were made by holding colored pieces of card in front of the camera one piece black and one piece white.
As you can see, there appears to be some kind of initialization / header / preamble at the beginning of each image @17.55 to @17.80 in this example. This allows the receiving device to detect that an image is about to be sent and determine the maximum amplitude of the signal. This maximum amplitude is then used as a scale factor during image decoding so that a lossy quiet phone line doesn't make the images being transferred lose contrast or brightness. Note: the signal you can see before @17.55 is simply noise on the line and isn't important for the operation of the VisiTel protocol.
Carrier wave --> "Silence" --> Carrier wave
In order to find these I implemented a simple FFT based detector and a finite state machine. First the waveform is transformed into the frequency domain. The detector then inspects each block of audio until it finds the carrier a strong signal at 1747Hz. Blocks are then inspected until the signal disappears and returns again. At this point the start of a transmission has been found. From here a simple static offset is used to find the beginning of the image data and the image decoding routines already discussed are utilized. Once an image has been decoded it is displayed and the finite state machine is reset in order to listen for the next transmission.
Step 3: Present the device as a webcam
. .(., , )
and whenever a new frame is available :
With that simple addition to the decoding program success. Zoom can now receive images from the VisiTel and we can video chat like it's 1988.
Going forward I'd love to setup a linux Direct Rendering Manager driver for this so that I can output images onto the VisiTel screen as well as receiving them. For now having the video capture setup and working in Zoom is enough for me to call this project a success.
I hope you enjoyed that write up. Check out the code on GitHub and please let me know if you setup your own VisiTel webcam https://github.com/Bostwickenator/VisiTel
Thursday, March 1, 2018
I was very impressed with the volume visualizations that Anatomage's viewer tool could produce but I wanted more. Not being able to read a file from your own health record with an open source tool didn't strike me as right. So started hacking away at the problem. The first breakthrough is that the Invivo viewer does not memory map part of it's own file directly with the volume data. Instead it extracts that data into your C:\ProgramData\ directory as Patient.inv and then loads it from there. A simple copy paste and we have a version of that file to play with.
Now that we have some data let's figure out what we can about the format. First off I opened Patient.inv up in Visual Studio Code which is generally a bad idea for a 70MB file but this showed me that the file started with XML. In fact the entire BLOB of the volume data is included inside the XML. There are also offset values stored in the XML. Presumably the offset values are used to skip the XML parser over binary data to avoid it throwing a fit.
More good news the XML tells us about the images, their sizes and encodings. However they were all in one large BLOB not one per image. The format specified for the images was J2K. This is a stream of JPEG 2000 data without the normal file container around it. I expected that this would mean that I would have to provide metadata to a JPEG 2000 decoder myself however it turns out that the image size is included in the bytestream itself. The only operation needed after some trial and error is to look for the magic bytes at the beginning of each image and chop the file up on those boundaries. This is not a very robust approach and your mileage may vary. With that said for my file it worked. The resulting JPEG 2000 files could then be fed to a decoder. Reading through one of the image files with a hex editor found that they were produced by the JasPer toolkit. Because of this I decided to choose ImageMagick to decode the images as ImageMagick included JasPer. It turns out that this information is out of date and ImageMagick has swapped to a new library. Luckily this new library handles the JasPer produced files just fine.
I've created a node script to automate the process of extracting the layers into PNG files which you can grab from GitHub here.
With that done we get exciting images like the one below.
|A raw PNG file from the stack (exciting right?!)|
These images have extremely low contrast but there is data there so now on to creating a 3D model that we can use. At first I was expecting to have to voxalize the data myself. However the Brazilian government came to the rescue with InVesalius 3.1 an amazing tool for processing medical data. We can simply load our PNG files into InVesalius and use it to produce a STL file. From there we can do just about anything we want with the model.
|Spooky Christmas ornament anyone?|
Monday, July 3, 2017
Thursday, May 11, 2017
This thing is a pretty large part which would be expensive to print completely solid. If you want to do that however you can buy one on Shapeways here.
To make a small production run I decided to use a cheap FDM print with low infill to make a mold. This part would not be strong enough to be functional but does a great job of being a positive of the shape. The mold was constructed out of silicone rubber and then a grip was cast with fiberglass reinforced epoxy. The resulting part is EXTREMELY strong and after a coat of paint looks almost exactly like the renders.
Tuesday, December 20, 2016
Alex's Framework Wisdom
- There is no free lunch. You will pay for free frameworks with ongoing development cost working around their oddities and/or contributing upstream. That is to say less CapEx means more OpEx. In the case of subscription licences it's purely OpEx as salaries or as licenses, either way you'll pay.
- The quality of the vendor is as important as the framework. You are piling your developer hours (your money) on top of these frameworks. The vendor has the ability to kill support at any time and transmute your beautiful codebase into a pile of technical debt with the snap of their fingers. If that worries you, get a contract that stipulates they won't.
- New isn't automatically better. New languages, new toolchains, new companies. On the surface these may be exciting and they may give you a market edge in some cases. Each one of them is however a double edged sword. These are a lot of companies out there using tried and true technologies because they work and they are known quantities. You should be one of these companies unless there is a pressing market reason that you cannot be. Using new things will make it harder to hire staff. The staff you do hire will create technical debt as they learn what works and what doesn't.
- Invest in training. When you choose a framework get your development team together to learn about it. It is crucial that this happens as a group. Received wisdom does not work well in the software industry. If all your team learns about something at once it will create homogeneity and accepted best practices. Handing a rulebook to developers will not work well they'll either ignore it or they'll all make disparate readings of it.
How to avoid choosing poorly
Congratulations you think you've found just the right combination of lego pieces to solve your business case. Not so fast! Before committing you (and by this I mean not you, I mean your staff) need to take it for a test drive.
- Apply at minimum your own standards. What does the framework's source look like? Is it public? If it's public review it. Makes sure it would pass the standards you set for your own code. If possible try fixing an open bug and getting it accepted upstream. If the framework is closed source you are especially dependent on the vendor. Look at the release notes and review the bug tracker. Make sure things are dealt with in a timely fashion.
- Consider the vendor's bus factor (how many of their team could get hit by a bus without impacting their ability to deliver). If it's a small number take this in mind. Will their business model keep them around at least as long as your product?
- Check out the debugger. Write something with a bug in it and hand it to a second developer. Their job is to document how the debugging tooling works while they find the bug. Did it run right out of the box or did they have to spend an hour setting up an environment? Does it hit every breakpoint? Are values presented in a useful way? Can it attach to a running process? Plus any other metrics your team might find useful here.
- Eyeball the UI. If it has a UI component take it to your UI and branding team. The default themes will not satisfy your business requirements. Get the UI team to specify the changes that will be required and then attempt to implement them. If this is difficult start worrying.
- Inspect the toolchain. Does it integrate with your CI setup? Can you make repeatable builds of your code over time. If not what would you have to do to internalize any build dependencies? Does it build in 1 second or 1 hour?
- Figure out how to test the end product. Does the framework have interfaces to test tools? Can you write a unit test, a functional test, and an integration test? Are the tests stable? If the framework has a UI component can you automate the UI testing or will you be paying people to click buttons?
- Consider reuse. Is the code you write in the framework coupled to it? Will you be able to take code from it to other places in your business? Will you be able to bring code into it?
Case study; Death by 1000 cuts (or Appcelerator Titanium)
Below are replies to some issues I have personally raised against a particularly hodgepodge framework known as Appcelerator Titanium. They are prime examples of the kind of bugs that will decimate your productivity should they occur with regularity. Also note these aren't even bugs with the framework these are bugs with the associated toolchain, remember to investigate the whole package you are buying into.
It's a little complicated. The available Titanium SDK releases depends on if you're using ti sdk vs appc ti sdk. appc ti sdk shows the latest and greatest SDKs. ti sdk shows the latest release before the switch from the Titanium CLI to the Appcelerator CLI.
The list of releases for the Titanium CLI is no longer automatically updated, but rather it's a manual process. Because we haven't determined which past releases should be available to ti sdk, we simply haven't updated the release list.
However, the list of releases that appc ti sdk reference is automatically updated and current, so I advise you just use appc ti sdk for now.
Smart quotes are not valid in XML. I wonder what the XML parser library is doing. I wouldn't be surprised if the platform was being parsed as "“iphone”". I don't think we should naively replace all smart quotes with ascii quotes and properly scrubbing the smart quotes is more effort than it's worth. In other words, I don't think we're going to improve this.
Trivial issues like the ones above and dozens more will slow your development process and make your project management unpredictable. This has a real fiscal impact. If a developer has a high chance of running into a framework bug or a hidden issue they will not be able to provide accurate estimates of effort to management. Without accurate estimates you will either miss release dates and stress your employees trying to make back time or have long release cycles and lose agility. Neither of these is going to help you make money.
Monday, December 19, 2016
With that warning out of the way and the freezer test having roused my suspicions I pulled the case off and took the motherboard out. iFixit has a great guide here for that process.
|Time to cook!|
Now that you have your motherboard separated from the phone's chassis preheat your oven to 195 degrees Celsius or 390 Fahrenheit whichever is appropriate for your current locale setting. While your oven is heating take out some aluminum foil and crush it into a ball. Un-crumple it so that there is still a rough texture as shown. This is going to help limit the heat transmission to the underside of the motherboard which we don't want to reflow. Place the motherboard on the foil and press it down. At this point attempt to get the board laying as flat as possible. You don't want parts sliding down the board on an angle if you overcook. Place the foil and motherboard on an oven safe cooking surface, a ceramic casserole dish will do nicely so long as it has a flat bottom, I used the spill tray from a waffle iron. So pick whatever looks good to you.
Remove your motherboard and let it rest until completely cool. Inspect the board for any physical damage, if you've really messed it up be extremely careful with reconnecting the battery. Who knows what you might have shorted out.
Reassemble your phone following the guide from iFixit and give that puppy a charge. Power it up and hope for the best!