Standalone serial monitor for macOS and Linux

Hi folks,

We’re a couple embedded systems engineers who made a serial monitor, Monitor. It’s easy to configure, allows you to quickly filter messages, append special chars to messages, and toggle between hex and ASCII-views.

I was hoping to get the Particle community’s thoughts on it so we can make it as easy to use and powerful as possible. If you’re interested, please sign up on the website to receive a copy. I look forward to your responses and thanks for the help! :slight_smile:

Keep tinkering,


Hi Nikita,

Your Monitor program looks great. I spun up a much simpler serial monitor program for my own use some time ago. My main motivation for doing this was that I hated the way most serial monitor programs required manual intervention around the connect and disconnect operations. As microcontrollers reboot and are re-flashed they disconnect their USB connection which is viewed by the OS’s as the tty closing. What my program does is continue to monitor the tty and automatically reconnect when it becomes available again. I cannot tell you how extremely valuable this has been to me. It is such a simple thing, and I would suggest you implement it.

Also, I have noticed recent behavior where the tty device that a USB connection is assigned to can change. In particular in MacOS for some reason the device name can sometimes start sequencing /dev/tty.usbxxxx1 then /dev/tty.usbxxxx2, etc… It is easy enough to query the /dev directory for tty.usb* and just connect to the one that appears. You may want to do something like this too.

I hope this helps and your project is successful.

  • Rich
1 Like

Hey Nikita,

Yep, nice tool/utility. I am normally a cheapskate using ‘particle serial monitor --follow’ in a terminal but I could see myself using your monitoring tool. As rvnash said, make sure to implement disconnect/reconnect ( the ‘–follow’ option).

I like your filtering custom option.But in addition to filtering the output, I would like to be able to color code it. So if we’d be able to add a highlighter keyword(s) and whereas the filter would remove all but the keyword(s) in the output, this would show everything but simply highlight the keywords as they fly by. Additionally, I would suggest that it would be nice to be able to save/recall a filter/highlighter set. This is nice if you want to switch out keywords from one debug session to the next.

The ‘save as’ menu saves the log as a JSON struct which seems for the purposes of loading it back into the monitor app at some other time. Though that might be handy at some time, I see little use for that in my case. A straight up TXT or RTF (to preserve color coding) would be easier. You’ve got those save log buttons sitting up on the right hand side but they are not active in my case.

Whats that View/Reload menu for?

Now if you really have a bunch more time on your hands (haha) - implement a simple scripting language that allows us to trigger on conditions occuring in the sequence of messages.


Oh, yeah! I would vote for that! Embedded Python?

Absolutely! Is there anything else besides Python (he said facetious…)

1 Like

Hi Rich – Thanks for the feedback. You’re right, automatic reconnection would be a really cool feature addition. I just gave your program a spin and can tell how much it helps. We’ll work on incorporating.

Hi joost – Thanks!

Ah, I love the highlighting suggestion. The option to save/recall a filter set will be part of our next release so I’m glad to hear it would be valuable. I’m interested in trying out highlighting in the next couple days to see how it turns out and possibly also add it to the release roadmap.

You’re a 100% right on the JSON structs. Will make sure we add support for .txt and .rtf too.

Now if you really have a bunch more time on your hands (haha) - implement a simple scripting language that allows us to trigger on conditions occuring in the sequence of messages.

This is actually really cool. What are your thoughts on implementing support for AT commands or even custom command sets as an alternative?

I personally do not have a use case for AT commands - my USB/serial port use is (mainly) for debug or other system messages, not for an interactive session. Interactivity goes across MQTT for me.

So when debugging I often find myself having to dig through loads of printf() output and it is sometimes a bit difficult to piece the logic that produced that output back together. Hence the (python) script language request. Another use for a script is to help dig through a more complex output such as an array of values. I could just dump the array with printf() with minimal processing on the target (so lower overhead) and let the backend script make sense from the output. Just some ideas. I guess this request is not unlike what Lua does for wireshark…

Forgive me if I didn’t understand the finer points of AT command capabilities.

Hi joost,

I see, sorry I misunderstood – I assumed you were talking from a debugging standpoint. Adding this to our issue tracker. :slight_smile: