Set the baud rate to 9600 with a [baud 9600( message to [comport].
On Windows, [comport] was somewhat broken until recently, especially
for writing. You'll need the latest test release to get the working
version:
http://at.or.at/hans/pd/installers.html
.hc
On Jun 19, 2006, at 10:12 AM, Ramirez Hugo Francisco wrote:
Dear Hans and Pd-list people. After doing some research through the patch I Have found that the comport is recognized and it will be opened, but the baud rate is 0!!! what seems to be the problem then?
Best Regards Hugo Ramírez
¡El pueblo unido jamás será vencido!
Continuing the cheapest servo controller in the world method, (not counting the computer)... I used a digital oscilloscope running at 50ks/s, so the best time resolution is 20us. Using a metro set to 20ms to send the number 0 through [comport], the jitter can be brought down to about 300us on my 200MHz linux pentium MMX linux machine. It is necessary to set the audio delay in Media->Audio Settings... to 20ms, that is, the same value as the metro. It is also necessary to enable and then disable "compute audio" on the main pd window. Leaving the audio enabled adds about 300us to the metro period, causing it to jitter at the 2ms level. Also, don't move the mouse or try to do anything else with the machine :(
It should be possible to control a single servo with this, but the output needs to be clipped so that it runs between 0 and 5 Volts instead of +/- 12 Volts. The easiest way to do this would be to put a 5Volt zener diode in series with a 1k resistor between the transmit data pin and ground:
TxD-----+
/
\ 1000 Ohm 1/4 Watt resistor
/
+-------------->to servo control
|
___
^ 5V zener diode
/
|
|
Gnd-----+-------------->to servo ground
A better way would use at least a transistor. For the same price as a single transistor an IC comparator like the LM311 running on the same power supply as the servo would be the best interface:
+5Volts-+-------to servo 5V
|\ | /
| \| \ 10k
Gnd----|+ \ / | ______________to servo control | / TxD----|- / | /| |/ | + Gnd-----------to servo Gnd
To control a servo, using 1200 baud, the numbers 0, 128, 192 and 224, 240 should position the servo roughly at 1/5 range steps. 240, 248, 252, 254 and 255 may be too short. The binary representation of these numbers is all 1s ending in all 0s. RS232 communications sends a 1 level (-12V) by default, and starts every character with a 0 bit (+12V). The least significant bit of each character is transmitted next, so to make variable pulse widths, 255 (all 1s) gives the narrowest pulse (just the start bit). Servo pulses are supposed to be at least 1ms and no more than 2ms, so 248 is probably as narrow as you can go at 2400 baud.
I fixed some more things with comport, but can't get them into cvs today (authorization failed, worked OK yesterday...). I'll try again tomorrow. Also I plan to make the DTR line settable so possibly that could be used as a cheap digital output as well. Martin
Martin Peach wrote:
To control a servo, using 1200 baud, the numbers 0, 128, 192 and 224, 240 should position the servo roughly at 1/5 range steps. 240, 248, 252, 254 and 255 may be too short.
That should be 4800 baud for 9 bits of 1/4800 seconds giving 1.875ms for the widest pulse. 4500 baud would give a 2ms pulse. Currently [comport] doesn't accept arbitrary baud rates even though they should be possible on modern hardware. I'll try it and see... (Adding messages to control the RTS and DTR lines worked OK in linux, but screws up data transmission, data is sent at unpredictable times. Probably needs to be flushed. I still need to implement the Windows version of this. )
Martin
Martin Peach wrote:
Martin Peach wrote:
To control a servo, using 1200 baud, the numbers 0, 128, 192 and 224, 240 should position the servo roughly at 1/5 range steps. 240, 248, 252, 254 and 255 may be too short.
That should be 4800 baud for 9 bits of 1/4800 seconds giving 1.875ms for the widest pulse. 4500 baud would give a 2ms pulse. Currently [comport] doesn't accept arbitrary baud rates even though they should be possible on modern hardware. I'll try it and see... (Adding messages to control the RTS and DTR lines worked OK in linux, but screws up data transmission, data is sent at unpredictable times. Probably needs to be flushed. I still need to implement the Windows version of this. )
Today I put a new version of [comport] and comport-help.pd in cvs at http://pure-data.cvs.sourceforge.net/pure-data/externals/iem/comport/comport... Now you can set dtr and rts lines to control things, also read the dsr and cts lines. This doesn't interfere with serial data transmission unless cts/rts or dsr/dtr flow control is enabled as well. Here it works in winXP and linux at least. As far as servos go, jitter is worse using the control lines: while the start of a pulse can be fairly accurately timed (using metro) to ~0.3ms, the end occurs at x ms or x+5ms regardless of the audio latency. It should work for switching on a coffee maker or a light though, just connect dtr or rts to a solid state relay. I suppose a [comport~] object could use a signal inlet for some kind of trigger to send a message that was set up on another inlet...any suggestions?
Martin
Hi Martin,
Martin Peach wrote:
I suppose a [comport~] object could use a signal inlet for some kind of trigger to send a message that was set up on another inlet...any suggestions?
A stupid question: why don't you use the printer port? You can control 8 digitial inputs/outputs there...
br, Piotr
Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
I suppose a [comport~] object could use a signal inlet for some kind of trigger to send a message that was set up on another inlet...any suggestions?
A stupid question: why don't you use the printer port? You can control 8 digitial inputs/outputs there...
Well for one, most laptops don't have parallel ports. Two, accessing the parallel port is problematic on recent versions of Windows. For some reason Microsoft thinks parallel ports are dangerous potential hazards and only those who can afford drivers should be allowed to access them. I don't know if a free-in-every-sense driver exists that could be incorporated into a pd external without issues, and I don't feel like writing one, it just seems like way too much work for nothing. Three, the parallel port will have the same timing problems as the serial port from pd: messages are handled between audio blocks so sub-millisecond timing is not really feasible. I myself find it much easier to build a circuit with a PIC microcontroller and a MIDI interface. I can precisely control 8 or more servos that way. (I can provide circuit diagram and code for anyone who's interested, for a few dollars more can program PICs as well...but you can also buy serial servo controllers for the price of a servo, like this: http://www.seetron.com/ssc.htm that also uses a PIC.)
Martin
br, Piotr
Martin Peach wrote:
Piotr Majdak wrote:
Hi Martin,
Martin Peach wrote:
I suppose a [comport~] object could use a signal inlet for some kind of trigger to send a message that was set up on another inlet...any suggestions?
A stupid question: why don't you use the printer port? You can control 8 digitial inputs/outputs there...
Well for one, most laptops don't have parallel ports. Two, accessing the parallel port is problematic on recent versions of Windows. For some reason Microsoft thinks parallel ports are dangerous potential hazards and only those who can afford drivers should be allowed to access them. I don't know if a free-in-every-sense driver exists that could be incorporated into a pd external without issues, and I don't feel like writing one, it just seems like way too much work for nothing. Three, the parallel port will have the same timing problems as the serial port from pd: messages are handled between audio blocks so sub-millisecond timing is not really feasible.
...but possibly a [parapin~] for linux only could be implemented that had much better timing. I'll look into it. Martin
Sounds like a crazy hack, but fun stuff for sure. Maybe this will
give some insight to serial port jitter in general when using
[comport]. I measured 0.5ms to 22 ms for roundtrip latency on the
serial port, with an average of around 12ms. So I guess that
translates to 0.25ms to 11 ms with an average of 6ms for just sending
or receiving.
But that is some serious jitter. I am wondering how much is caused
by the hardware and/or OS buffering and how much is caused by Pd and
the [comport] object. It would be nice to reduce the jitter caused
by [comport] as much as possible.
.hc
On Jun 19, 2006, at 10:04 PM, Martin Peach wrote:
Continuing the cheapest servo controller in the world method, (not
counting the computer)... I used a digital oscilloscope running at 50ks/s, so the best time
resolution is 20us. Using a metro set to 20ms to send the number 0 through [comport],
the jitter can be brought down to about 300us on my 200MHz linux
pentium MMX linux machine. It is necessary to set the audio delay
in Media->Audio Settings... to 20ms, that is, the same value as the
metro. It is also necessary to enable and then disable "compute
audio" on the main pd window. Leaving the audio enabled adds about
300us to the metro period, causing it to jitter at the 2ms level.
Also, don't move the mouse or try to do anything else with the
machine :(It should be possible to control a single servo with this, but the
output needs to be clipped so that it runs between 0 and 5 Volts
instead of +/- 12 Volts. The easiest way to do this would be to put
a 5Volt zener diode in series with a 1k resistor between the
transmit data pin and ground:TxD-----+
/ \ 1000 Ohm 1/4 Watt resistor /
+-------------->to servo control | ___ ^ 5V zener diode /
| | Gnd-----+-------------->to servo groundA better way would use at least a transistor. For the same price as
a single transistor an IC comparator like the LM311 running on the
same power supply as the servo would be the best interface:+5Volts-+-------to servo 5V |\ | / | \| \ 10kGnd----|+ \ / | ______________to servo control | / TxD----|- / | /| |/ | + Gnd-----------to servo Gnd
To control a servo, using 1200 baud, the numbers 0, 128, 192 and
224, 240 should position the servo roughly at 1/5 range steps. 240,
248, 252, 254 and 255 may be too short. The binary representation
of these numbers is all 1s ending in all 0s. RS232 communications
sends a 1 level (-12V) by default, and starts every character with
a 0 bit (+12V). The least significant bit of each character is
transmitted next, so to make variable pulse widths, 255 (all 1s)
gives the narrowest pulse (just the start bit). Servo pulses are
supposed to be at least 1ms and no more than 2ms, so 248 is
probably as narrow as you can go at 2400 baud.I fixed some more things with comport, but can't get them into cvs
today (authorization failed, worked OK yesterday...). I'll try
again tomorrow. Also I plan to make the DTR line settable so
possibly that could be used as a cheap digital output as well. Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hans-Christoph Steiner wrote:
Sounds like a crazy hack, but fun stuff for sure. Maybe this will give some insight to serial port jitter in general when using [comport]. I measured 0.5ms to 22 ms for roundtrip latency on the serial port, with an average of around 12ms. So I guess that translates to 0.25ms to 11 ms with an average of 6ms for just sending or receiving.
But that is some serious jitter. I am wondering how much is caused by the hardware and/or OS buffering and how much is caused by Pd and the [comport] object. It would be nice to reduce the jitter caused by [comport] as much as possible.
I got the same or worse jitter on WinXP at 2GHz as on linux at 200MHz. I don't think [comport] causes any jitter, it's all in pd's scheduling. (MIDI is jittery too at the same level at least when triggered by metro, but I can't hear it listening to an external synthesizer). All that happens inside [comport] is the calls to the OS to do things with the serial port. These may be queued by the OS but probably not for milliseconds. I suppose I should try writing a dedicated c program to periodically write to the serial port and check the jitter there. Possibly some sort of periodic metrocomport object could run in its own thread and send data at a frequency determined by one of its inlets... As far as hypothetical [comport~] or [parapin~] objects go, I don't see how to get finer timing than the audio block size in pd with a dsp object, since it's the sound hardware that handles the timing there, with no feedback available (i.e. which sample is at the DAC right now). Is it possible?
Martin
-
Hans-Christoph Steiner -
Martin Peach -
Piotr Majdak