I have a Lasersaur, which is an arduino-based open-source laser cutter. Part of its capabilities is raster engraving, where you etch images based on pixel data, rather than vector data. Recently I started experiencing a weird issue where I am losing some of the data that I am sending over serial to the machine, and the end of the image gets cut off. I don't believe those details are relevant to this question, but you can read my posts here for more info.

Basically, on my old Laptop B, engraving works. If I use the exact same USB hardware connection, firmware, frontend software executable, engraving settings, and image file on my current Laptop A, I see bad results. The last ~20 pixels or so of each image line are not etched in, and the only reason I can think for this is that the color data for these pixels were not sent in the first place. Notably, Laptop A used to work a few months ago when I last tried this out. So I'm pretty confident that I've ruled out hardware and rx/tx software as the possible issues.

The only difference between the two machines that I can think of that has changed since then is that I installed the Windows 10 1909 update, as well as some other software that I would have to dig back through to list out. I'd really like to not do a fresh Windows reinstall on my primary machine, but I'm close to that point.

Could something there be causing an issue? I'm out of my depth at this point, and don't know how either the operating system or another program could be affecting serial data transfer, and wouldn't know the first way to narrow it down.

Some more thoughts which may or may not be important:

  • There does not seem to be data corruption, only data loss. The rx/tx protocol implements some error detection (sends every byte twice and checks for equality), and I am not seeing error corruption messages that would pop out if that were the case.
  • There does not seem to be any randomness. The same behavior happens for images of different widths (leading me to think that the tx buffer isn't filling up), is the same for each image line, and has always been consistent.
  • The Arduino in the machine is an Arduino Uno R3. Compilation is done using the Arduino compiler on some custom C code (not though the IDE).
  • 1
    Do you know in which format data is sent to the arduino, does it transmit the whole image, separate lines or seperat pixels? I also suspect buffer problems. Can you print what ever is received by the atmega? Generally I don't believe that a windows reinstallation would help
    – Sim Son
    Commented Dec 9, 2019 at 23:08
  • It's a custom protocol, wherein bytes from 0-127 are message flags and 128-255 are data. The image is broken up into a list of horizontal lines. The laptop sends configuration data (power level, pixel size in mm, travel speed, etc), then the starting and ending coordinates of each raster line, then a stream of bytes that has a grayscale value for each pixel. This repeats one line at a time, so the image isn't being sent at once. For the test image I'm using, there are about 400 pixels in each line but I've used test images with ~5000 pixels in each line and it's still only the last 20 or ...
    – Scott
    Commented Dec 9, 2019 at 23:18
  • 1
    Are you sure that your new laptop causes the problem (be it the different OS or what ever) and that there hasn't been a firmware change since you last tried successfully? Simple test: connect tx to rx on the pc side and compare if the frontend sw sends what it's supposed to send.
    – Sim Son
    Commented Dec 9, 2019 at 23:22
  • 1
    To further investigate, what exactly is being send, you could use another Arduino/microcontroller and let it snoop on the PCs TX line.
    – chrisl
    Commented Dec 10, 2019 at 8:44
  • 1
    As an alternative to @chrisl's proposal (that is a good one!) you could change the Arduino's code to count the received bytes and show them in some appropriate way. What OS is your laptop B running on? Commented Dec 10, 2019 at 10:52

3 Answers 3


The driver board for your "Lasersaur" appears to be based around the Adafruit Trinket Pro.

That board, on Adafruit's website, is deprecated, with the following warning:

Deprecation Warning: The Pro Trinket bit-bang USB technique it uses doesn't work as well as it did in 2014, many modern computers won't work well. So while we still carry the Pro Trinket so that people can maintain some older projets, we no longer recommend it.

So basically the USB interface is naff. It's too slow to keep up with modern computers (hence your old laptop works but your new one doesn't), and you lose data.

You should look into the possibility of upgrading the controller board to something a little more modern and capable.

For UNO R3 based boards there is another fundamental flaw: there is a 64 byte receive buffer and no flow control. That means if you send data too fast - faster than the board can process it - data will be lost.

  • Hmm, did more digging and it looks like the board that's supposed to be in the machine is an Arduino Uno R3. I'll pop off the lid when I get home today to check, but could you point me towards where you saw that info? My understanding was that if I'm communicating at the correct baudrate there shouldn't be a thing as "sending too fast", but I could be wrong there. Maybe I could try artificially slowing down the transmission rate...
    – Scott
    Commented Dec 10, 2019 at 17:25
  • 1
    Which? What the device should be, or the deprecation warning?
    – Majenko
    Commented Dec 10, 2019 at 17:27
  • What the device should be, I was able to find the deprecation warning.
    – Scott
    Commented Dec 10, 2019 at 17:32
  • 1
    @Scott That was the result of a lot of digging. The manual led me to a GitHub repo. In there was a bill of materials. In that was a link to a fritzing file for the pcb. In that was the trinket.
    – Majenko
    Commented Dec 10, 2019 at 18:14
  • Today I learned about fritzing. I assume this was the repo? github.com/nortd/driveboard/tree/master/DriveboardUSB Thanks! You've given me a lot to go track down.
    – Scott
    Commented Dec 10, 2019 at 18:22

I have solved the bug, you can see the writeup on the Lasersaur google group. The short of it was that this was a software bug, which was only being triggered when the hardware conspired to have some timing delays. I'm still unclear why the behavior was inconsistent previously - I must have been on the borderline of the data delays causing an issue or not.


Well, I was able to resolve it, but I’m not sure how. After going through the steps I’ve outlined in my replies to answers here, I tried buying a new Arduino Uno R3, but that didn’t fix anything either. My last step was to do a Windows “Reset” which reinstalls Windows while keeping files but resets settings and programs. After reinstalling and adding back in all the programs I originally had, the serial communication worked again. I really don’t have a good explanation as to why this worked, but at least it did.

Edit: This problem reappeared, and the windows reset did not fix the issue this time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.