Did this in 1991-92 to capture mailing lists for a cable company subscriber list. they had a "mainframe" no one in the local office understood, and could order it to print bills. I had a "lunchbox" laptop with a parallel port and a laplink cable and some whacked together DOS software that would read the printed stream and translate that to CSV suitable for database input. We were sending out weekly local "TV guides" to their subscribers for a couple years before they had a channel that showed schedules.
My recollection is that the laplink cable Just Worked and reading the data off the hardware wasn't that hard. The parsing and reformatting of the data was a bigger challenge.
This is cool because the raw data included the text, so you didn’t have to OCR or anything. Unfortunately the same today might be harder depending on the situation you’re thrown in - I think if you are given PCL printer output there’s a good chance it’s all been rasterized before being sent to the printer. Budget printers are now removing all parsing from the printer (given sufficient bandwidth over the interface, unlike with parallel or serial ports, or even USB 1.0) in the name of cost cutting and rasterize the entire output on the PC, then send the entire page at 300dpi with some line compression to the printer - which is why the printed text always has a soft, almost blurred look.
(Ironically yesterday was the first time I had trouble with my Postscript printer configured to always download soft copies of fonts from the PC; I was printing in Arabic from MS Word and the printer was making the strokes so bold all the letters connected. Converting to a PDF and printing from Adobe did the trick.)
yeah it had some "printer codes" formatting but it was like ANSI terminal stuff, easy enough to parse out and the rest was all plain ascii and simple. at the time the system might've been set up for a Postscript printer and that would've been practically impossible to do anything with.
Heh, back in the days before customers names where Robtert'); DROP TABLES users;--
Things were a weird mix of harder and easier back then. You'd have to flip magic switches on chunks of hardware to multiple times so things would speak, but in general you didn't worry about your data attacking the computer.
Great to see something like this here. That's how the company I now run started back in the 90ies.
Back then (and earlier, but that stuff stays around) alarm receiving centers had reaceiving devices that just printed everything they received on strips of paper. So if they received a burglary alarm somthing like
ID: 1234
Status 00001000
apperead and the operator had to grab a folder, search for the ID and then read to see what he had to do, when the 5th line went from 0 to 1.
Our company built devices that connected to the printing ports (most of the time internal connections on the main board) of the machines, interpret the data and automate the lookup against files (later a database).
I like the idea of soldering the Pico directly to the bottom of the board. I would have tried to duplicate the Pico design with all of the components, made several errors, and given up. Soldering on a tested unit for a total BOM cost of $1 extra is just smart.
Duplicating the design isn't super hard to do, there's reference schematics available that you can just copy. I suspect the real reason is that the QFN56 package of the RP2040 chip has a thermal pad below it that requires hot air to solder.
It not being super hard is exactly why that would be the first thing I'd think to do, but even with it not being super hard, you can still route something wrong or forget a component. I really like OP's idea better. It's ugly and I'd hate myself for that, but the "time to working device" goes way down. Make it smaller after the prototype works.
I've soldered these kind of packages with a hot air gun in the past. The reason to use a Pico instead of an rp2040 is because many have a Pico already in their component box, it works, it's reliable, and after factoring in the cost of power regulator, USB connector etc, the cost difference is almost nothing.
I loved the writeup and all the details - mad props for making this so simple and to the point.
However, I must say that I actually prefer the pictures of the scope to the "raw graphs" you posted. Maybe it's just because I'm familiar with them but I find the oscilloscope pics to be much more legible and more immediately understandable than the b&w images you posted, possibly because their lines aren't as bold and clear.
I'd just use something like the Lens app by Microsoft on my phone to take the picture and automatically deskew, rotate, and crop.
Yeah, for the TDS 420A, a real picture will show the background (grid etc) with lower intensity than the actual signal while the bitmap is just black and white. So you definitely have a point there. A TDS 784D with a color display has a multi-color bitmap and doesn't have that problem.
But for the spectrum analyzer, I definitely prefer the bitmap.
I haven't tried HPGL output, but when you select "Enscapulate Postscript Color", it still outputs mono. The same setting on a 784D creates a color output.
I did a lot of google searches to see if there was anything else out there, but this one never showed up.
Your design is even simpler, using just an FT245 chip. Surprisingly, that FT245 cost $4.80, only 20 cents cheaper than the Raspeberry Pico that I'm using, and the final BOM cost differs by only $2.
I love that it fits in an enclosure (at the cost of needing more space in the back.)
In fact I kind of like the pico (or any mcu) idea better in the long run.
The only reason I made this is because I wanted there to be a more generic (not tied to a particular sbc, not tied to any particular software) and open source option for the key hardware part of retroprinter.
Well for future-proofing and open sourceness, code that runs on an mcu or hdl to configure an fpga is better than this because in this all the magic is inaccessable and immutable inside that chip, while code or hdl can be shared, modified, iterated, used 20 years later regardless if FTDI or myself are still around or not, and by a 12 year old kid with no money or permission. Even if the pico goes away, and even if the code is making full use of the pico's special pio features, the code is still useful, while if this chip goes away, there's essentially nothing left here that's useful.
And of course obviously the pico (or any mcu or fpga) is infinitely more flexible than whatever's hardcoded in the ftdi chip. And no worries that FTDI will release a driver that bricks your chip some day.
Why are people doing all of this SMD stuff for hobby projects? Cool project, but that looks like a maddening build. Would be a fun afternoon if it was THT.
Because the only reason you think through-hole is easier is that you're accustomed to it.
Starting from scratch, a syringe of paste and some tweezers is not only easier, it's faster and smaller. Young eyes might not even need a magnifying glass. There's no pile of sharp little trimmed leads everywhere afterward, even!
I teach newbies SMT all the time at my local makerspace. It's insanely easy.
Here's at least one very good reason: the 74LVC161284 buffer is only available as SMD. 0603 resistors and caps are pretty easy to solder by hand and you can buy convenient component boxes with a hundred different values that take up the space of a book.
Soldering the whole thing together took less than an hour. Having a microscope definitely helped.
There's nothing maddening in soldering 0804/0603 SMD if you have the right tools. With a good flux you can even do it with your eyes closed. Smaller sizes require at least a magnifying glass and a steady hand though.
I tried that first, but I'm terribly at judging the amount of solder paste needed. The result was a bit of a disaster, so I took my losses and switched to hand soldering.
Did this in 1991-92 to capture mailing lists for a cable company subscriber list. they had a "mainframe" no one in the local office understood, and could order it to print bills. I had a "lunchbox" laptop with a parallel port and a laplink cable and some whacked together DOS software that would read the printed stream and translate that to CSV suitable for database input. We were sending out weekly local "TV guides" to their subscribers for a couple years before they had a channel that showed schedules.
My recollection is that the laplink cable Just Worked and reading the data off the hardware wasn't that hard. The parsing and reformatting of the data was a bigger challenge.
This is cool because the raw data included the text, so you didn’t have to OCR or anything. Unfortunately the same today might be harder depending on the situation you’re thrown in - I think if you are given PCL printer output there’s a good chance it’s all been rasterized before being sent to the printer. Budget printers are now removing all parsing from the printer (given sufficient bandwidth over the interface, unlike with parallel or serial ports, or even USB 1.0) in the name of cost cutting and rasterize the entire output on the PC, then send the entire page at 300dpi with some line compression to the printer - which is why the printed text always has a soft, almost blurred look.
(Ironically yesterday was the first time I had trouble with my Postscript printer configured to always download soft copies of fonts from the PC; I was printing in Arabic from MS Word and the printer was making the strokes so bold all the letters connected. Converting to a PDF and printing from Adobe did the trick.)
yeah it had some "printer codes" formatting but it was like ANSI terminal stuff, easy enough to parse out and the rest was all plain ascii and simple. at the time the system might've been set up for a Postscript printer and that would've been practically impossible to do anything with.
Heh, back in the days before customers names where Robtert'); DROP TABLES users;--
Things were a weird mix of harder and easier back then. You'd have to flip magic switches on chunks of hardware to multiple times so things would speak, but in general you didn't worry about your data attacking the computer.
Great to see something like this here. That's how the company I now run started back in the 90ies. Back then (and earlier, but that stuff stays around) alarm receiving centers had reaceiving devices that just printed everything they received on strips of paper. So if they received a burglary alarm somthing like
ID: 1234
Status 00001000
apperead and the operator had to grab a folder, search for the ID and then read to see what he had to do, when the 5th line went from 0 to 1.
Our company built devices that connected to the printing ports (most of the time internal connections on the main board) of the machines, interpret the data and automate the lookup against files (later a database).
On a similar note, I just bought a Greaseweazle. Floppy disc to USB capture.
https://github.com/keirf/greaseweazle
I've been through some childhood 5 1/2 inch floppies. Some still work. Found some old BBC BASIC programs. Very nostalgic.
I like the idea of soldering the Pico directly to the bottom of the board. I would have tried to duplicate the Pico design with all of the components, made several errors, and given up. Soldering on a tested unit for a total BOM cost of $1 extra is just smart.
Duplicating the design isn't super hard to do, there's reference schematics available that you can just copy. I suspect the real reason is that the QFN56 package of the RP2040 chip has a thermal pad below it that requires hot air to solder.
It not being super hard is exactly why that would be the first thing I'd think to do, but even with it not being super hard, you can still route something wrong or forget a component. I really like OP's idea better. It's ugly and I'd hate myself for that, but the "time to working device" goes way down. Make it smaller after the prototype works.
Correct, anything with a thermal pad on the underside of the package is designed for reflow soldering process.
I've soldered these kind of packages with a hot air gun in the past. The reason to use a Pico instead of an rp2040 is because many have a Pico already in their component box, it works, it's reliable, and after factoring in the cost of power regulator, USB connector etc, the cost difference is almost nothing.
Every tablet, when plugged into a computer, should present a fake printer device so you can "print" to PDF documents to it.
Thanks for the brainworm
https://streamable.com/t9rycs
And yes that is the Steam Deck USB gadget working as a printer.
That seems like it shouldn't be hard to write as an Android app for any kernel that has USB gadget support... hmmm!
Oh hey.
https://www.kernel.org/doc/Documentation/usb/gadget_printer....
It works!
https://streamable.com/t9rycs
You maniac.
I loved the writeup and all the details - mad props for making this so simple and to the point.
However, I must say that I actually prefer the pictures of the scope to the "raw graphs" you posted. Maybe it's just because I'm familiar with them but I find the oscilloscope pics to be much more legible and more immediately understandable than the b&w images you posted, possibly because their lines aren't as bold and clear.
I'd just use something like the Lens app by Microsoft on my phone to take the picture and automatically deskew, rotate, and crop.
Thanks!
Yeah, for the TDS 420A, a real picture will show the background (grid etc) with lower intensity than the actual signal while the bitmap is just black and white. So you definitely have a point there. A TDS 784D with a color display has a multi-color bitmap and doesn't have that problem.
But for the spectrum analyzer, I definitely prefer the bitmap.
Can you configure the scope for plotter output? That may choose different pens for the grid versus the trace.
I haven't tried HPGL output, but when you select "Enscapulate Postscript Color", it still outputs mono. The same setting on a 784D creates a color output.
https://github.com/bkw777/LPT_Capture
I did a lot of google searches to see if there was anything else out there, but this one never showed up.
Your design is even simpler, using just an FT245 chip. Surprisingly, that FT245 cost $4.80, only 20 cents cheaper than the Raspeberry Pico that I'm using, and the final BOM cost differs by only $2.
I love that it fits in an enclosure (at the cost of needing more space in the back.)
In fact I kind of like the pico (or any mcu) idea better in the long run.
The only reason I made this is because I wanted there to be a more generic (not tied to a particular sbc, not tied to any particular software) and open source option for the key hardware part of retroprinter.
Well for future-proofing and open sourceness, code that runs on an mcu or hdl to configure an fpga is better than this because in this all the magic is inaccessable and immutable inside that chip, while code or hdl can be shared, modified, iterated, used 20 years later regardless if FTDI or myself are still around or not, and by a 12 year old kid with no money or permission. Even if the pico goes away, and even if the code is making full use of the pico's special pio features, the code is still useful, while if this chip goes away, there's essentially nothing left here that's useful.
And of course obviously the pico (or any mcu or fpga) is infinitely more flexible than whatever's hardcoded in the ftdi chip. And no worries that FTDI will release a driver that bricks your chip some day.
You're right about moving the code to a different MCU: mine is pretty much a straight copy of the Rue's Atmega version. :-)
Why are people doing all of this SMD stuff for hobby projects? Cool project, but that looks like a maddening build. Would be a fun afternoon if it was THT.
Because it's actually easy and fast, and through hole rework is a pain.
I say this from the point of view of an electronics manufacturing tech, so YMMV.
Because the only reason you think through-hole is easier is that you're accustomed to it.
Starting from scratch, a syringe of paste and some tweezers is not only easier, it's faster and smaller. Young eyes might not even need a magnifying glass. There's no pile of sharp little trimmed leads everywhere afterward, even!
I teach newbies SMT all the time at my local makerspace. It's insanely easy.
Here's at least one very good reason: the 74LVC161284 buffer is only available as SMD. 0603 resistors and caps are pretty easy to solder by hand and you can buy convenient component boxes with a hundred different values that take up the space of a book.
Soldering the whole thing together took less than an hour. Having a microscope definitely helped.
There's nothing maddening in soldering 0804/0603 SMD if you have the right tools. With a good flux you can even do it with your eyes closed. Smaller sizes require at least a magnifying glass and a steady hand though.
on a similar vein but with software we wrote about hooking Microsoft Windows functions to capture printing details [1].
[1] https://blog.nektra.com/main/2012/05/18/logging-printer-acti...
Seems like the solder paste + hotplate method would be preferable to hand soldering, especially for that buffer chip.
I tried that first, but I'm terribly at judging the amount of solder paste needed. The result was a bit of a disaster, so I took my losses and switched to hand soldering.
A lot of work to save $200 not buying a retro-printer HAT and Pi, but more fun too.
I much prefer spending that $200 on an old RF signal generator on craigslist that I'll never use!
Very cool! Next step - live display to a screen :)