Hi all long time lurker first time poster here please be gentle..
i have some scales which chuck out serial data over a usb cable, took me a while to find a suitable pc driver but once i did all i needed to do was to point putty at the virtual com port to get a scrolling screen of current state and weight.
So next step is getting the arduino mega reading the data.. i soldered up a usb header and using serial1 pins 18/19 i loaded up the few lines of the example sketch
*/
void setup() {
// initialize both serial ports:
Serial.begin(9600);
Serial1.begin(9600);
}
void loop() {
// read from port 1, send to port 0:
if (Serial1.available()) {
int inByte = Serial1.read();
Serial.write(inByte);
}
// read from port 0, send to port 1:
if (Serial.available()) {
int inByte = Serial.read();
Serial1.write(inByte);
}
}
opening up the serial monitor just provided me with a single growing line of unprintable characters (squares) ???
swapping rx and tx over resulted in nothing getting spat out, so i had done the null modem cross over.
the serial spec of the data transmited is 8 bits no parity and 1 stop bit, i cant see how to jiggle this with the arduino??
as you can probably tell im on shakey ground here, my approach to my project is to work with all the h/w with simple coms test sketches before bringing everything together, this is the last bit of h/w i need to sus out.
opening up the serial monitor just provided me with a single growing line of unprintable characters (squares) ???
Is the device operating at 9600 baud?
Is the Serial Monitor set to operate at 9600 baud?
Why are you sending binary data to an application that expects ASCII data?
Is the device operating at 9600 baud?
Is the Serial Monitor set to operate at 9600 baud?
Why are you sending binary data to an application that expects ASCII data?
Yes both scales and arduino ide serial monitor are set at 9600 baud rate, (default for both)
Why are you sending binary data to an application that expects ASCII data?
forgive me i dont fully understand the question, my (limited) understanding is that the example sketch is reading byte by byte from either serial connection and echoing it back to the other.
the data output from the scales is ascii text a 4 chatacter string denoting the ID and state, change up change down, static, followed by a space and then the numerical mass reading in whatever unit selected, a text abreviation for the unit ie Kg followed by a newline every few ms..
i am guessing because the bytes/characters are not being understood by the arduino/serial monitor its not using the same definition of what a byte is?? tho it may well be something else way more headslapingly DOH!
its been well over a decade since i sat for hours at the codeface
forgive me i dont fully understand the question, my (limited) understanding is that the example sketch is reading byte by byte from either serial connection and echoing it back to the other.
Is the device sending binary data or ASCII data? The Serial Monitor application expects ASCII data, as output by the Serial.print() method, not binary data as output by the Serial.write() method.
Try changing the Serial.write() calls to Serial.print().
Not even the whole snippet as i ended up commented out the condition regarding the base port.. most perplexing!! must have been a short in my soldering?? NO ?? pulled the usb header and it still was flashing the Tx led but not a single flash of the Rx led??
restart with no wires connected and picking up the board/touching the header for the 15-21 pins would stimulate a Tx flashing frenzie??
I would gladly pour you a pint Paul,,
my goal in reading the scales output is to automatically control the filling of a mash tun in my nano brewery.
So far i have code for implementing the arduino pid lib for heating up the liquor with one wire temp sensors, pump control, and even a big red BREW button on a 3.2" tft,
so just the gui (yawn) to work hard on.. once i sort out the scales comms
more thought and investigation, the tx flashing is behaviour i dont understand, so lets eliminate it
further reading led me to the serial event handler code below
so i lifted and edited the code to include a serial1 and redirect serial1 input to serial(0)
my data in is an alpha numeric string
viewed in a terminal emulator
String inputString = ""; // a string to hold incoming data
boolean stringComplete = false; // whether the string is complete
void setup() {
// initialize serial:
Serial.begin(9600);
Serial1.begin(9600);
// reserve 200 bytes for the inputString:
inputString.reserve(200);
}
void loop() {
// print the string when a newline arrives:
if (stringComplete) {
Serial.println(inputString);
// clear the string:
inputString = "";
stringComplete = false;
}
}
/*
SerialEvent occurs whenever a new data comes in the
hardware serial RX. This routine is run between each
time loop() runs, so using delay inside loop can delay
response. Multiple bytes of data may be available.
*/
void serialEvent() {
while (Serial1.available()) {
// get the new byte:
char inChar = (char)Serial1.read();
// add it to the inputString:
inputString += inChar;
// if the incoming character is a newline, set a flag
// so the main loop can do something about it:
if (inChar == '\n') {
stringComplete = true;
}
}
}
this loads and runs and does little. no mad tx led lashing, but no rx flashing or output in the serial monitor either ;(
just to recap on what im doing i have a female usb header i solderd 4 wires to it and plugged it into the arduino as follows
USB pin1 to arduino +5v
USB pin 2 usb rx to arduino pin 18 (serial1 Tx)
usb pin 3 usb Tx to arduono pin 19 (serial1 Rx)
usb pin 4 to arduino gnd.
the arduino isnt picking up on the data , i unplug the usb from the female header plug it into a pc and point a termninal emulator at it and recieve the data ???????
i swapped Rx and TX to be sure no result...
i swapped +5 and gnd just in case i read the pin out spec upside down, and it shut off the scales. Whoops!! so the wiring is sound?? .
i have some scales which chuck out serial data over a usb cable, took me a while to find a suitable pc driver but once i did all i needed to do was to point putty at the virtual com port to get a scrolling screen of current state and weight.
That means the the scales are a USB slave, just like the Arduino. The scales are sitting there waiting for you to ask them to send some data.
Unfortunately, because the scales are expecting the command from the driver, which is a USB master, and the Arduino is a slave, you can not send the commands to the scales.
You'll need a USB host shield, and you'll need to write the corresponding driver for the USB host shield, to make it talk nice to the scales.
i have some scales which chuck out serial data over a usb cable, took me a while to find a suitable pc driver but once i did all i needed to do was to point putty at the virtual com port to get a scrolling screen of current state and weight.
That means the the scales are a USB slave, just like the Arduino. The scales are sitting there waiting for you to ask them to send some data.
Unfortunately, because the scales are expecting the command from the driver, which is a USB master, and the Arduino is a slave, you can not send the commands to the scales.
You'll need a USB host shield, and you'll need to write the corresponding driver for the USB host shield, to make it talk nice to the scales.
Oh B*gger at least i can stop banging my head against this particular wall for now..
a quick delve into the win inf file tells me its a usbcdc acm device, and google led me to
and
Whats involved in writting a driver for the USB host shield, to make it talk nice to the scales tho?? that sounds a bit iffy.
Whats involved in writting a driver for the USB host shield, to make it talk nice to the scales tho?
http://www.circuitsathome.com/ has done a lot of work on get various USB devices to play well with the USB Host shield. There might be something there that is interesting, or maybe someone there knows.
Indeed there is, cheers.. as there is already a usb scales interface defined, looks like a simple substitution for a description of my output and how its handled and its almost out of the box, no doubt i will have many hours of debugging typos and errors ahead..