Problem Receiving From Arduberry with jSSC-2.6.0

I am attempting to communicate with the arduberry on a raspberry pi 2 using java and jSSC-2.6.0. I have created a little test program and a sketch based on your examples. I wired an LED to pin 8 (I too figured out the PIN 13 problem) to indicate that the arduberry received the communication from the RPI. The data seems to send fine as the LED lights when it should, but I never get the correct response from the arduberry. I setup a SerialPortEventListener to read and printout the response on a RXCHAR event when the eventValue equals 10. Nothing is written out. I did some debugging in the java program and determined that I get one response of only 4 bytes, not 10 and it is gibberish.

I also tested the communications with your python program and it worked perfectly, so there is something wrong in the java program, but everything seems fine. Is there some configuration or parameter that is unique to the arduberry serial communications that I need to allow for? I really would like to get 2 way communications working in java, so any suggestions would be welcome.

Since the Serial Port is working with Java ( you mentioned that you are getting 4 bytes) and the python program also works properly, I am not so sure what the problem is. Can you post the program that you are using, maybe it’s something trivial and I might be able to help. I don’t know much about Java so I am not so sure if I would be able to help you a lot. Maybe you can post this problem is in Stackoverflow or somewhere else where people might have used the same package before and might be able to provide some insight.


Kara, thanks for the reply. I gave up on jSSC as it seemed to be the problem. I have since gotten RXTX to work with the Arduberry and I am able to control a couple of servos for a pan and tilt rig. One factor that I discovered with testing first on an Arduino and my laptop is that you need to wait >1 sec after opening the serial connection to transmit. I left this in my program when I moved it over to the RPI 2. I don’t know yet if it is really necessary with the Arduberry as I am busy trying to get OpenCV face detection working on the RPI. The video capture works fine, but not the face detection which is what I need to drive to position the servos. BTW how much current can I push through the RPI to the Arduberry before I have to start using a separate power supply?

I don;t think it is necessary to wait for a second before starting serial. I think that wait might be there to make sure that the connection is properly established.

So, the Arduberry has an Atmega328 at heart and it can give 50mA of current on each of the I/O pins. If you draw too much current at an instant, it’ll cause the voltage to drop and the Pi might reset. We have seen this a lot. Are there any specific reason that you are worried about the current usage. The Pi can supply upto 1.2A on teh USB so I think it would be more than capable of handling the current but just make sure that there are no sudden changes in the current draw.

Do share you project with us when it’s done and we have a contest running on Instructables too (, share it there and you might win some awesome goodies too.


You are correct, it is not necessary to wait before using the serial connection to the Arduberry. The face detection is working pretty well, not as well as on my laptop with an outboard Arduino, but acceptable. From what information I was able to find on the web for similar projects using the RPI B+, the RPI 2 can handle a frame rate about 5 or 6 times higher at twice the resolution.

I am not sure what I am ultimately going to build; I just exploring the capabilities of the RPI 2 and the Arduberry. I have one small gripe with the Arduberry so far. There isn’t any good way to add standoffs to support the board. Inserting wires in the header on the unsupported side of the board causes significant movement of the board and I can only think that stacking shields on top it will just make it worse.

Do let us know what kind of performance you get out of Pi2 and Open CV. We had tried a bit earlier to get OpenCV to work on the old Pi and the performance was just acceptable, nothing great.

Also, there should be a hole near the MicroUSB side of the Pi2 which should align with the hole on the Arduberry. You should be able to add a hex post there and that should make the Arduberry much more stable.


I found the performance with opencv to acceptable at 7 fps and 640x480 resolution. At those parameters the face detection was both reliable and quick enough to make the webcam response to movement reasonable. You can probably push the frame rate a little more, but there starts be a significant delay in the webcam movement. I guess I should also state that I am using the haarcascade_frontalface_alt2.xml file for the classifier with a 1.4 scale factor, min neighbors of 3, min size of 50x50 and max size of 500x400.

I will let you know how the face recognition works once I have the code written. Most of the preprocessing examples seem to be in Python and I prefer to code in Java. I will probably look at some C++ code to figure out which functions to use to prepare the images.

The RPI 2 that I have only has 4 holes at the edges, but I suppose I could use one of the holes in the Arduberry with a plastic standoff to add some stability. The holes seem to align with a relatively clear spot on the RPI 2. I will look for an appropriate height standoff and give it a try.

Do share your project with us once it’s done. It would be great to have a blog post around it.


Hi Kim123,

The data might be in operating system buffer which is not read by library and therefore not delivered to application. How are you reading data from serial port.

I would like to introduce you to scm which is an alternative library to rxtx/javaxcom.
Wiki :
Repository :
Video :

It supports RS-232 control signals handshaking, monitoring and has been ported to Linux, MAC, Solaris and Windows operating system. It is consistent, portable, efficient, reliable, testable, extensible, modifiable, scalable library.