The good news is that my IR Toy v2 gets successfully enumerated as /dev/ttyACM0 on Linux and I also managed to update its firmware to v22. When I execute screen `/dev/ttyACM0 115200` and type "s", "S01" appears and when I point my remote towards the IR Toy v2 and press a button the LED flickers and gibberish gets displayed on the screen.
The bad news is that when I execute `irtoy -d /dev/ttyACM0` it displays "Opening IR Toy on /dev/ttyACM0 at 115200bps..." and gets stuck there. Also, when I execute `irrecord -n -H irman -d /dev/ttyACM0 RemoteXXX.conf` it displays "Hold down an arbitrary button.", then I hold down a button, then it displays "irrecord: gap not found, can't continue" and gets stuck there.
Just wanted to follow up that I've successfully updated to the v22 firmware. Now when I send "v" to my IR Toy v2 it displays "V222" in the terminal. Looks like the format is VXXY where XX is the firmware version and Y is the product version (2nd generation IR Toy).
@AnalysIR: Thanks for the help! After executing `screen /dev/ttyACM0 115200` and typing "v", "V212" appeared. I'm not exactly sure which version it's supposed to mean. I only know that according to http://dangerousprototypes.com/docs/USB ... y#Download v22 is the most recent version. Any ideas?
Thanks for the idea! In the meantime I've managed to solve this issue. I believe that RX picked up noise because it was floated. Upon connecting it to an IC it started to behave correctly.
If I disconnect the probe cable and solder RX and TX together on the Bus Pirate board then the monitor doesn't read any excess bytes, but echo still doesn't work. If I touch TX with my finger then I receive these bogus bytes again. Looks like some electo-magnetic / capacitive noise.
So this makes this problem two-part: 1) the lack of echo and 2) the EMI / capacitive issue.
I have a Bus Pirate v3 and using 38400 baud 8N1 UART with RX and TX interconnected. I'd expect in Bus Pirate this scenario to echo the bytes on RX that I send on TX but when live display is enabled it shows:
READ: -f 0x00 READ: -f 0x00 ...
without me sending anything. Is this normal? How should I echo bytes?
@2blmaster: I haven't encountered with any of such errors, so far my stencils were perfect (not that I created that many). Maybe you could fine-tune the behavior of gerber2graphtec through its parameters.
@xl97: I'm afraid you won't go too far on Windows because the script uses Unix device filenames. Linux surely cuts it (pun intended) and maybe Mac OS, too.
Yes, a Mac would definitely be a better choice than Windows because of its Unix legacy. The README file does a decent job at listing the dependencies and giving some instructions for Mac. I don't have any better idea, unfortunately.
No matter what operating system you're using, I'm pretty sure that you should be able to make the gerber2graphtec tool work. It might not be the most user friendly application out there but it does work. So far I only cut stencils out of gerber files using this tool so it's all I know. If you have any specific questions, feel free to ask me.
The relevant thing to note is that I haven't ever used the bundled Silhouette Studio software because I use Linux and it's not available on Linux. Even if I could have used it I wouldn't because I'm fairly sure that it's not optimized for super-precise cuts like for fine-pitch stencils. Intead I rather used the https://github.com/pmonta/gerber2graphtec script. I don't know how much of a command line guy you are but this tool basically receives gerber files and outputs Graphtec files that can be directly sent to the cutter.
I'm fairly certain that the generated Graphtec file takes a LOT longer to cut than what Silhouette Studio would have done because the cutter recalibrates (goes to the origin coordinates) very often, moves slowly and only draws horizontal or vertical lines in one pass instead of turning from horizontal to vertical in one pass (and mess up corners).
Right now I'm unable to shoot close-ups because I'm away from my cutter but I'll be able to make some pretty pictures about a week later if you want me to, but let's just say that I couldn't be more satisfied with the result.
I'd like a purchase a QS-5180C or some similarly large model from Qinsi. Googled for it but most of the sites are Chinese and I'm not sure which sellers are reliable / cheap. Could you recommend a seller?
Given the relevant protocols being binary it makes sense to design a new protocol that is also binary, so I can understand your choice.
Despite the above I believe that a Bus Pirate-like command line interface wolud be the best choice usability wise for many people. Representing bytes as hex values would certainly impose some performance penalty, there's no way around that but that performance loss may be tolerable.
In the future adding a slide switch or DIP switch to the IR Toy could make it boot into a Bus Pirate-like console friendly mode or into the already existing binary mode. This is just an idea, I don't expect anyone jumping into that. :)
