[SOLVED!] Help with getting serialosc to recognise Arduinome [button presses now solved]

  • Hi all,

    I'm just starting out on the Arduinome experience, and I'm running into a few problems, specifically at the "getting my computer to talk to it" stage. If any of you have any suggestions, they'd be much appreciated. I've read through a whole bunch of threads on this forum already, but nothing I've read so far seems to quite match where I'm at.

    The Arduinome:
    I'm using the basic sparkfun breakout boards and button pads, with an Arduino Mega 2560 r2 and a stripboarded shield. It appears to all be wired up correctly - I can get the LEDs to behave exactly as expected using the LedControl library in Arduino.

    Computer setup:
    - I'm on a Mac running 10.6.8.
    - Arduino 1.0 is working fine, and I've used it to install ArduinoFirmware v3.3 on the Mega.
    - I've successfully installed serialosc (after an initial fight with the permissions, as others on the board have also found) - I can now see it running happily enough in Activity Monitor.
    - Max6 runtime appears to be working fine, and I've made sure those zeroconf files have been put in the max-externals folder.

    The problem:
    I think I've managed to change the serial number okay following the steps on FlipMu at http://flipmu.noisepages.com/work/chronome/changing-the-serial-number/ , but there are curious inconsistencies between how things show up in different software (which may or not be part of the problem):
    - At the "changing the Descriptors.c file" part I substituted in "a40h-456".
    - In the System Profiler it shows up as "a40h-456" as expected.
    - In Arduino's Tools->Serial Port menu it appears as "/dev/tty.usbmodema40h-451".
    - In ArduinomeSerial it appears in the device menu as "0h-451". (with serialosc switched off, as I'm told these two conflict).
    - In monome_test_1.1 it doesn't show up at all (with either serialosc or ArduinomeSerial running). The program appears to be running fine, but it just doesn't DO anything!
    - With serialosc running, when I plug the Arduinome in I don't get the "serialosc [chr-844]: connected, server running on port 14407" message I am told to expect.

    So, my question really is "what do I do next?"
    Are there specific settings I need to change in ArduinomeSerial? (Checking the Test Mode box or clicking the Clear LEDs button momentarily light the RX light on the Mega, but otherwise nothing else happens.) Is the odd serial number behaviour above likely to be part of the problem?

    Any help or suggestions hugely appreciated. Let me know if there's any info you need which I missed out. Thanks for taking pity on a newbie!


  • A couple of screenshots in case they're of any help...

    412 x 588 - 50K
    468 x 255 - 58K
    309 x 156 - 13K
  • Hi Josephiah,

    Are you building an Arduinome or a Chronome? From your post "basic sparkfun breakout boards and button pads", it looks like your building an Arduinome.

    If this is the case, then you might have to change a few things.

    For starters, most Arduinomes are built using the smaller UNO, but there is no reason the Mega wouldn't work if the pins lined up correctly.

    Secondly, you should see something like a40h-xxx or 0h-xxx. Sometimes the characters get cut off depending on how serialosc or arduinomeserial parse the string when they see the device. Don't worry too much about that. As to the numbers changing after flashing... I've seen that before, but I'm not sure what causes it? However, it also doesn't seem to mess with anything.

    If you are seeing chr-xxx then you've somehow flashed the serial number with the chronome info.

    My advice (if you're building an Arduinome) would be to use an UNO instead of a mega, and then flash the serial number using the instructions at this link.


    Again, you should be able to flash the mega with an a40h-xxx serial number and have it work, but I'm not sure if their would be any weirdness.

    Hope that helps.

  • Hi Owen,

    Thanks very much for your quick reply. In answer to your question: both!

    I've used RGB LEDs on the boards for future expandability, but am starting with an Arduinome using only one colour channel at the moment. The plan is to eventually replace my Arduinome stripboard shield with a Chronome one. At this stage, however, Arduinome all the way until I get my head around how it all works!

    I followed the serial-change steps on your Chronome page, as that was the one which matched my Mega board, but set it to "a40h-456" rather than a "chr-xxx" type number.

    Having just looked through both sets of instructions the ONLY differences I can find are:
    1. in the makefile at lines 71-74 where the PID is chosen.
    2. in Descriptors.c where I choose the serial number.

    So I'm reasonably confident now that flashing the serial number has been successful using the Chronome/Mega instructions but setting the serial number to "a40h-456" rather than "chr-xxx".

    Anyway, time for bed - I'll have another fiddle with the software tomorrow, and then be back for the next part of the problem!

    Thanks for your help,

  • //EDIT, half an hour later: Think I've got it now, more or less. Is the "0xFE" just the same as saying "B11111110" and so on? I may have been making it more complicated than it really was...//

    **EDIT 2: Okay, after some perusal of the [[http://arduino.cc/en/Hacking/PinMapping2560|Mega pin mapping diagram]] I think I've sorted the pin mapping. In the process I made colour coded port diagram to help my thinking - it's attached below in case anyone else might find it helpful.**


    I've been reading up on the pin and port assignment stuff trying to work out how I need to alter the assignments for using my Mega, and I think I'm getting a reasonable handle on how it works.

    However, I have a question about this section in the firmware v3.3:

    > // IMPORTANT - you'll need to make sure that you set the data following two direction register variables to match your pin assignments.//
    > byte PORTD_Data_Direction = 0xFE;
    > byte PORTB_Data_Direction = 0xFD;

    How did you determine that these should be 0xFE and 0xFD? I can't quite figure out what these lines are doing exactly. If you (or anyone else) can help me understand how you got to this, it'd be a big step on my way!


    1280 x 720 - 151K
  • Okay, on to the next part of the problem...

    Where I'm up to:

    - The Mega is flashed with serial number "a40h-456" (without quotes). It shows up with the new serial number in System Profiler, Arduino, and ArduinomeSerial as mentioned in the first post.
    - After writing my own test sketch in Arduino, I'm pretty certain the buttonpads and stripboard shield are wired up correctly. The LEDs light as expected, and I can collect input data from the buttons, again working as expected.
    - With the firmware loaded up, it now does the quick little line-by-line light-up on startup.
    - ArduinomeSerial appears to connect to it - please see attached screenshot for what it's giving me in the GUI. Checking the Test Mode box toggles all the LEDs on; pressing buttons doesn't appear to do anything. Which brings me to:

    **Question 1:** I haven't managed to find any documentation or hints as to what the various boxes and settings in ArduinomeSerial are supposed to do/be - is there a tutorial somewhere that will explain it to me? The readme file is frustratingly empty!

    - SerialOSC appears to run happily in the Activity Monitor, but I've never seen it do anything visible - no "serialosc [a40h-xxx]: connected" messages or anything of the sort.
    - monome_test_1.1 appears to run fine in Max6 runtime, but doesn't appear to connect, whether through SerialOSC or ArduinomeSerial - any suggestions?

    Any suggestions/hints/pointers to tutorials/etc gladly welcomed!

    412 x 588 - 50K
  • Can you share the test patch you created in Arduino? I think I'm experiencing the same problem as you however, I have only tested my buttons using the max patch and they are not registering (I'm not familiar enough with the Arduino code to create a test patch myself). I'm pretty sure my buttons are working though as the arduino flashed when the buttons are pressed.

    When I use SerialOSC i don't receive the "serialosc [a40h-xxx]: connected" message either. It would be interesting to know if this is the case when using a fully functioning arduinome.

    My max patch does connect however. When you open yours and try to connect, does it display the name of your arduinome (a40h-xxx) in the connect box?

    Also, are you aware that you should not run serialOSC and ArduinomeSerial at the same time as this causes them to fight to communicate with the board?

    Another thing I find interesting here is that I created my circuit using stripboard as well and maybe we have both made the same error in this process. I followed this diagram:


    How about you?

  • Also, have you tried it on a windows machine? I am planning to try this tonight.

  • Hi dgrizzle, I'll attempt to answer each part separately:

    **Sharing test patch:** Yes, certainly, but I'll come back to you with that soon once I've had a chance to comment my code in some kind of intelligible way. It's pretty clumsy, but just allowed me to check the basic functions of the circuitry separately from the serial communication issues.

    **monome_test_1.1 Max patch connection:** No, mine doesn't show any action whatsoever. The drop-down menu in the bottom left corner has "monome 64 (m64-0028)" and "monome i2c (m0000190)" as options, neither of which appear to do anything. Again, if anyone can point me to some documentation/tutorials for this, that'd be great.

    Interestingly, I discovered that opening the Max Window (command-m) gives the following:

    * binding to port 17812
    * binding to port 11101
    * binding to port 28131

    The numbers are generated randomly each time, but clicking the M button and setting the port to the 3rd one changes "not connected" to "prefix: /example", matching the Address Pattern Prefix box in ArduinomeSerial. So //some// kind of communication is happening. The buttons and LEDs still don't do anything though.

    **SerialOSC/ArduinomeSerial:** Yes, I'm aware that these conflict with each other - I've tried everything with each separately.

    **Stripboard diagram:** Yes, I used that as a starting point; however, there's a few things which aren't quite right, especially with the numbering of the MAX chip pins. I found it helpful to create a patching area on each side of the MAX and use jumpers to get the pins connected in the right order. This made the wiring to the buttonpads much more ordered and logical (jiparis's seems to be optimal in terms of lowest number of jumpers required, but I found my way much more intuitive - each to his own!). See the attached diagrams for my version.

    Also, as the A and B inputs to the 164 chip are AND-gated together, you'll probably need to either tie them together or tie one of them to +Vcc.

    **Windows:** I don't have access to a Windows machine unfortunately (or, perhaps, fortunately :o) ). I look forward to hearing how you get on with it tonight.

    Are you also attempting to use a Mega, or are you using the usual Uno?


  • dgrizzle, here's my test code. It's pretty clumsy, but it let me see that my basic hardware was working okay. Feel free to ask any questions.

  • I actually found the Serial Monitor in the Arduino software and found that the software is definitely responding to my buttons. The Max patches still do not though and therefore my problem is definitely within my software configurations somewhere. I haven't got round to trying it on a windows machine. I will do today.

    I'm using a duemilanove ATMega 328.

    It sounds like your serialOSC is not talking to Max in the right way. When your arduinome is connected, open up activity monitor and search serialosc and take a screen shot.

    As far as I know, it should look something like the file I have attached (however, mine is not fully functional, but as you can see, the drop down menu in Max displays the name of my unit)

  • Yes, it's definitely a software problem. Here's the screenshots - pretty much the same as yours except unconnected.

    The 2nd one is what happens after I've clicked "M" and entered the 3rd port number - still unconnected, but picks up "/example" from somewhere.

    I've also included a shot from the serial monitor (I just changed a couple of the "serial.print"s to "serial.println"s to print on new lines) - is that like what you get? Seems to be 1st digit = button state, other digits = button address.

    P.S. why do you have two instances of serialosc running in your activity monitor?

    615 x 352 - 26K
    589 x 602 - 66K
    1391 x 606 - 124K
  • @Josephiah

    You should see n+1 instances of serialosc, where n is the number of devices currently plugged in.

  • paste me the output of

    > ls -l /dev/tty.usbserial*

    (without quotes, in a terminal). it looks like serialosc doesn't recognize your device as being a monome, which is potentially what's going on with arduinomeserial too.

  • @marto

    Useful to know, thanks.


    Yes, I think you're probably right. Terminal responds with:

    ls: /dev/tty.usbserial*: No such file or directory

    I read a few other threads about making sure the flashed serial no. was right, which may or may not be something to do with it. (Mine has serial no. a40h-456, which shows up as detailed in earlier posts above). So yes, they seem to be spotting the device, but not recognising it as a monome.

    One other thing I noticed which may or may not be relevant: The first time connecting after flashing the serial no, I get an alert along the lines of "a new network device has been detected, and do I want to go to network settings to set up this device". Does this happen with other peoples' devices too? Or might it be specific because I'm using a Mega?

  • Hi all, I have some progress to report! - big thanks to visinin for his helpful suggestions.

    visinin spotted that my device was showing up as "tty.usbmodem", not "tty.usbserial", requiring patches to serialosc and libmonome so that Mac OS X correctly recognises the Uno/Mega-based devices

    (In case it helps anyone else stuck on the same problem, I patched serialosc as suggested by owen_Vallis in [[http://post.monome.org/comments.php?DiscussionID=13239|this thread]], and libmonome using the patch suggested by visinin at https://github.com/monome/libmonome/pull/15 )

    So, a quick update on the behaviour, with the unresolved bits highlighted:
    - serialosc now appears to notice the Arduinome, and spawns the 2nd process in Activity Monitor when plugged in.
    - **I still haven't ever seen the "serialosc [a40h-xxx]: connected, server running on port xxxxx" message.** Does this matter? (Incidentally, //where// should I be seeing the message? Should it be an OSX pop-up, or a response in Terminal, or something else?)
    - monome_test now recognises the device, lists it in the drop-down menu and allows me to connect (Yay!).
    - **In monome_test, I'm not convinced the behaviour is quite right yet:**
    - clicking the squares in the left-hand ("key") grid toggles the square and the corresponding LED (good, I think).
    - without going into the details of every permutation, with the 'link' menu set to 'momentary' or 'toggle', clicking the squares in the right-hand ("led") grid sets the squares and LEDs in ways which make sense.
    - the LED intensity dial behaves as expected.
    - **pressing the buttons on my grid doesn't appear to do anything** (other than making the tx light on the Mega flash as expected).
    - With max6 and serialosc turned off, I can run the Arduino software's serial monitor and see sensible-looking serial data being produced, of the form of a 1 or 0 for button state, followed by a number for button address (column 0: 0-7, column 1: 16-23, and so on...).

    (monome_test has that frustration common to much homebrew software, that the documentation (or lack of) leaves one wondering "what behaviour am I //supposed// to get? And therefore, how do I go about troubleshooting it? - if there's a tutorial or any tips somewhere that I've missed, please point me in that direction!)

    So if anyone has any suggestions for getting my button presses recognised, that'd be amazing!

  • @Josephiah

    I'm seeing the same behavior on a different hardware setup. I had an arduinome that I built a few years ago using the sparkfun buttons and a diecimila that I recently pulled out of the closet and have been trying to get running. It was previously working properly using arduinomeserial and the older firmware and I've been trying to get it up and running using the new firmware and serialosc.

    It sounds like I'm seeing the same issues that you are but I'm running Windows 7 64-bit. All of the applications that I've tried to run see the device and appear to connect properly. Any of the applications in monome_test or monomebase that send light information to the device work fine, and when I disable serialosc and turn on the arduino serial monitor I can see data being sent by the button presses.

    Kind of frustrating to know that it worked using the old software and I'd like to avoid putting all of that back together, so any advice from people have been able to get this working would be appreciated.

  • Hi space_moose,

    Yeah, it seems like there's a few people seeing similar symptoms. In that case, I wonder if it's worth trying with older versions of the software to see if we find any better results? I'm willing to give it a shot if someone can suggest the versions which have worked for them in the past.

    Or alternatively, is there anyone who'd be willing to update all their software to the newest versions to see if they get the same problems?

  • I'm still stuck on this as well. I contacted Owen Vallis directly (one of the dudes that created the Flipmu site) and he gave me this advice:

    "Hard to say what it could be but you might want to try a few things.

    Since you can send LED info to it, it sounds like the serial number flash did work and that the serial number is being recognized.
    If thats the case, I might suggest turning off serialosc and trying arduinomeserial instead. You'll be able to see whats happening a little easier, and you can send MIDI to Ableton for testing. This eliminates Max/MSP from the signal chain, and should make it a little easier to test
    you can only run one serial app at a time, so you can type killall serialosc in terminal to stop serialosc, or there is another, cleaner command someone posted on the forum that also works
    If that doesn't help point to the problem, you can pull the Chronome copy of libmonome and add a print statement to the src/proto/40h.c file in the "proto_40h_next_event(monome_t *monome, monome_event_t *e)" function
    you'll need to add #include to the top of the file with the other includes
    to print you just type fprintf(stderr, "press Down\n"); where ever you want to see if you're getting data
    pulling and building serialosc from scratch is laid out here http://flipmu.noisepages.com/work/chronome/chronome-serialosc/

    If its none of those things, then it sounds like it must be a hardware issue. I would start with a multi-meter and trace down all the button connections.

    Let me know how it goes,"

    I am in the process of installing and trying to get it working with ableton. Has anyone else tried any other sortware?

    @ space_moose - do you know what version of the firmware you were using before? And are you using the unsped shield?

  • Mine's working! I uploaded the old firmware (3.2) and it's working how i would expect it to! I guess there maybe a bug in the new firmware possibly...

    I downloaded the firmware 3.2 from here:


    but to use it with the latest version of arduino, I had to make some amendments to the code. See here:


    I have attached the file that worked for me :)

    Let me know if it works for you guys. What a relief!

  • YES!! Well done sir.

    3.3 is fine too, it's just that the "Serial.print"s need to be changed to "Serial.write"s. My monome_test is now working perfectly - looking forward to trying out some proper apps.

    Thanks everyone for you help!

  • Josephiah,

    Sorry for the delay in getting back to you regarding your arduinome issues, I had partially given up, but it appears you may actually be in a position to help me solve mine thanks to your Button_LED Arduino patch.

    I have checked my cable wiring 15 times now and am confident that I have the cables connected correctly. When I run your test patch all of my lights turn on with the exception of one row (it appears this is a row from the below message), also I receive this repeating message in the Arduino Serial Monitor, regardless of any button presses:

    col=0 rowbits=10000000 rowdata=11111111 lights=0
    col=1 rowbits=10000000 rowdata=11111111 lights=0
    col=2 rowbits=10000000 rowdata=11111111 lights=0
    col=3 rowbits=10000000 rowdata=11111111 lights=0
    col=4 rowbits=10000000 rowdata=11111111 lights=0
    col=5 rowbits=10000000 rowdata=11111111 lights=0
    col=6 rowbits=10000000 rowdata=11111111 lights=0
    col=7 rowbits=10000000 rowdata=11111111 lights=0

    col=0 rowbits=10000000 rowdata=11111111 lights=11111111
    col=1 rowbits=10000000 rowdata=11111111 lights=11111111
    col=2 rowbits=10000000 rowdata=11111111 lights=11111111
    col=3 rowbits=10000000 rowdata=11111111 lights=11111111
    col=4 rowbits=10000000 rowdata=11111111 lights=11111111
    col=5 rowbits=10000000 rowdata=11111111 lights=11111111
    col=6 rowbits=10000000 rowdata=11111111 lights=11111111
    col=7 rowbits=10000000 rowdata=11111111 lights=11111111

    To me this seems like a hardware issue on my Unsped shield. Perhaps you could explain this line a little bit more, and help direct my attention to what could be causing my Arduino from not recognizing button presses, I am not that familiar with the ICs used.

    Any help would be much appreciated; I am almost wondering if it is worth rebuilding the Unsped with all new components.

  • Hi alx,

    I'll try and explain what you should be seeing (though to be honest I had to go back and figure it out for myself! - it was very much a sloppily shoved together piece of code which I lost interest in as soon as it had served its purpose...)

    Here's an example of what I get when I hold down a diagonal line of four buttons starting in the bottom left corner.

    col=0 rowbits=11111111 rowdata=0 lights=0
    col=1 rowbits=11111111 rowdata=0 lights=0
    col=2 rowbits=11111111 rowdata=0 lights=0
    col=3 rowbits=11111111 rowdata=0 lights=0
    col=4 rowbits=11101111 rowdata=1000 lights=1000
    col=5 rowbits=11011111 rowdata=100 lights=100
    col=6 rowbits=10111111 rowdata=10 lights=10
    col=7 rowbits=01111111 rowdata=1 lights=1

    (I'm never entirely sure whether I'm dealing with columns or rows, but that's just a matter of orientation. As I'm looking at it just now, columns and rows appear to be switched round.)

    'rowbits' and 'rowdata' are showing the same information (the state of the buttons) but in different ways. The 8x8 block of 1s and 0s after "rowbits=" is essentially a map of which buttons are currently being pressed. So as you can see in this example it's showing me 0s corresponding to the diagonal line of buttons I'm pressing.

    'rowdata' is showing the same data in the form of a byte (it's a little harder to read as the leading zeros are missing, and I was too lazy to make it display better).

    'lights' corresponds to the state of the LEDs - as you can see these are the same as the buttons pressed in 'rowdata'. Those four LEDs are now lit on my button grid. The LEDs stay lit once I've let go of the buttons, like below:

    col=0 rowbits=11111111 rowdata=0 lights=0
    col=1 rowbits=11111111 rowdata=0 lights=0
    col=2 rowbits=11111111 rowdata=0 lights=0
    col=3 rowbits=11111111 rowdata=0 lights=0
    col=4 rowbits=11111111 rowdata=0 lights=1000
    col=5 rowbits=11111111 rowdata=0 lights=100
    col=6 rowbits=11111111 rowdata=0 lights=10
    col=7 rowbits=11111111 rowdata=0 lights=1

    Pressing the button of a lit LED will toggle it off again at the next refresh.

  • So, on to the troubleshooting.

    First thing: Did you set the pins in the test code correctly? You'll need to make sure that they are set right for the hardware setup you have - there are 8 pins to check in the pin assignments section of the code, controlling the MAX72xx LED driver, and the 74hc164 and 74hc165 shift registers (which between them handle the button matrix). I'm unfamiliar with the routing of the unsped shield, so you may need to trace to find which arduino pin is connected to which IC pin - the pinout diagrams on the IC datasheets will be essential for this - a quick google search should get them.

    The fact that your rowbits and rowdata are showing //different// things seems a little weird. Are all your lights toggling on and off with each refresh? (change the value of "interval" in the code to slow things down to a readable speed, though I guess you found that already.) It looks to me like it thinks all the buttons are being held down all the time...

    Have you tried controlling just the LEDs with the LedControl examples? Any success?

    Apologies if this is aimed at a patronising level - I had to work a lot of it out from scratch myself (still am!), and obviously I don't know if you're ahead of or behind me in your learning on different subjects! :o)