DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
atommann has joined #qi-hardware
viric has quit [Ping timeout: 260 seconds]
viric has joined #qi-hardware
atommann has quit [Ping timeout: 272 seconds]
atommann has joined #qi-hardware
kyak has joined #qi-hardware
xiangfu has joined #qi-hardware
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #qi-hardware
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu has joined #qi-hardware
pcercuei has joined #qi-hardware
wej_ has joined #qi-hardware
wej has quit [Ping timeout: 265 seconds]
wolfspraul has joined #qi-hardware
jluis has joined #qi-hardware
wolfspraul has quit [Ping timeout: 260 seconds]
wolfspraul has joined #qi-hardware
xiangfu has quit [Ping timeout: 272 seconds]
xiangfu has joined #qi-hardware
astr has quit [Ping timeout: 272 seconds]
astr has joined #qi-hardware
astr has quit [Ping timeout: 244 seconds]
atommann has quit [Ping timeout: 240 seconds]
astr has joined #qi-hardware
xiangfu has quit [Ping timeout: 245 seconds]
astr has quit [Ping timeout: 245 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
astr has joined #qi-hardware
Luke-Jr has quit [Excess Flood]
Luke-Jr has joined #qi-hardware
atommann has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
atommann has quit [Quit: Leaving]
<DocScrutinizer05> hey, maybe somebody here can help me out. Trying to control a PSU (PPS-11xxx Voltcraft http://www.reinhardweiss.de/german/sonstiges.htm) via shell, and everything finally works with "echo -e GMOD\r >/dev/ttyUSB0". But I can't for the life of mine find the right stty setting to set up the tty so it does convert <ENTER> into a "\r" (e.g. a "cat >/dev/ttyUSB0" simply doesn't work, no matter what I do via stty). Am I suffering some
<DocScrutinizer05> misconception there regarding what stty can do and that it maybe doesn't work at all for cat>somwehere, or is there a trick how to use the stty parameters?
<DocScrutinizer05> in short: what do I need to do so the "\r" in "echo -e GMOD\r >/dev/ttyUSB0" is not needed anymore?
jekhor has joined #qi-hardware
pcercuei has quit [Ping timeout: 250 seconds]
<roh> DocScrutinizer05: forget stty and similar pita. (serials termios suck).. take pyserial and hack up a python script
<roh> also some drivers forget the settings on serial close, so you cannot properly set stuff on shellscripts
<DocScrutinizer05> well, you can, opening tty on evak on fdN
<DocScrutinizer05> eval 4<ttyUSB
<DocScrutinizer05> been there, done that. but it seems stty and/or ioctl of tty doesn't work like supposed to
<DocScrutinizer05> I wrote a stepper motor controller a while back, and I ran into exactly same problem back when. Seems tty doesn't obey what man 1 stty suggests onlcr etc are supposed to accomplish
<DocScrutinizer05> talk2controller(){echo -en "$@\r"}
<DocScrutinizer05> which is kinda insane
<DocScrutinizer05> tty driver SHOULD handle this
<DocScrutinizer05> I wasted 4 hours trying to talk to that sucker PSU via minicom
<DocScrutinizer05> no luck, probably just because I wasn't able to terminate COMMAND by \r
<DocScrutinizer05> there must be a bug in tty driver since 2007
<DocScrutinizer05> at least
<DocScrutinizer05> but hey, you might be right, I tried to set ourput properties before output channel (fd) been opened
<DocScrutinizer05> nope :-/
<DocScrutinizer05> I seem to recall some settings in /dev/tty* were sticky and stty didn't take effect on second time. But I forgot what to do to reset the tty, except the obvious powercycling
<DocScrutinizer05> sounds like http://stackoverflow.com/questions/7812142/how-to-toggle-cr-lf-in-gnu-screen >>In the past, onlcr didn't work on USB to serial adapters using the pl2303 driver. That bug has been fixed, but some devices use old Linux kernels. – dreamlayers Nov 1 '11 at 2:26<<
jekhor has quit [Ping timeout: 260 seconds]
jekhor has joined #qi-hardware
jekhor has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
jekhor has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
<DocScrutinizer05> LOL
<wpwrak> i'm speechless :)
viric has joined #qi-hardware
<kyak> every kid's dream :(
<wpwrak> DocScrutinizer05: (serial) roh has a good point there - you often need more control over the comm channel with this sort of devices than you may expect. it's VERY common to run into subtle communication problems.
<DocScrutinizer05> ok, now I know *I* have a problem (=bug), not stty.
<wpwrak> heh, good timing, eh ? :-)
<DocScrutinizer05> yep
<DocScrutinizer05> echo -e 'GETD\r' >/dev/ttyUSB0
<DocScrutinizer05> works
<DocScrutinizer05> echo -e 'GETD' | tr \n \r >/dev/ttyUSB0
<DocScrutinizer05> doesn't
<wpwrak> and yes, what i meant is bugs :) e.g., my fluke sometimes fails to answer. then you have to restart the connection. but that sometimes fails too, but only after the next operation.
<wpwrak> the rigol DS1xxxCD has a whole catalog of such issues, apparently caused by lack of internal flow control. `C, ~D, and ~E probably, too. (same platform)
<wpwrak> these are the two i use(d) the most. so i know their bugs best. i think the picotest DMM (usbtmc) also has some quirks
viric has quit [Read error: Connection reset by peer]
<DocScrutinizer05> well, whatever
<wpwrak> naw, you really want to know exactly which bytes are going over the line and when. with shell scripts you're at a far too high level.
<DocScrutinizer05> I'm not able to grok what's going on with \r on my shell
<wpwrak> e.g., you'll probably also run into timing constraints. things like having to wait for the unit to process a command before it can accept the next (without overrunning buffers). etc.
<DocScrutinizer05> echo -e 'GETDx\n' | tr x \r >/dev/ttyUSB0 fails
<wpwrak> you can see with strace what really happens underneath
<DocScrutinizer05> is \r a delimiter that gets handled even in pipes?
<wpwrak> but it's easier just to write these things in C
<DocScrutinizer05> or what?
<wpwrak> if you want a library that gives you access to such stuff, you could look here: https://gitorious.org/lab-tools/tmc
<DocScrutinizer05> meh, escaping
<wpwrak> low-level comms in C, the rest in python. there's also lib/power.py with very simple power supply control
<DocScrutinizer05> saturn:~ # echo -e 'GETDx\n' | tr x \r | od -xa
<DocScrutinizer05> 0000000 4547 4454 0a72 000a
<DocScrutinizer05> G E T D r nl nl
<DocScrutinizer05> saturn:~ # echo -e 'GETDx\n' | tr x \\r | od -xa
<DocScrutinizer05> 0000000 4547 4454 0a0d 000a
<DocScrutinizer05> G E T D cr nl nl
jekhor has quit [Ping timeout: 272 seconds]
<DocScrutinizer05> \o/ I'm not completely braindamaged
<DocScrutinizer05> saturn:~ # echo -e 'GETD\n\n' | tr \\n \\r >/dev/ttyUSB0
<DocScrutinizer05> saturn:~ # 040200000
viric has joined #qi-hardware
<DocScrutinizer05> saturn:~ # echo 'GETD' | tr \\n \\r >/dev/ttyUSB0
<DocScrutinizer05> saturn:~ # 040200000
<DocScrutinizer05> alas this still doesn't explain why damn stty reduses to do same like tr does, despite
<DocScrutinizer05> * [-]onlcr
<DocScrutinizer05> translate newline to carriage return-newline
<DocScrutinizer05> suggests it should
<DocScrutinizer05> refuses*
<DocScrutinizer05> saturn:~ # stty -a </dev/ttyUSB0|grep onl
<DocScrutinizer05> -opost -olcuc -ocrnl onlcr -onocr onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
<DocScrutinizer05> ((lib/power.py)) sorry what?
<DocScrutinizer05> I find backup-20090831/usr/share/paroli/services/hardware/power.pyo and /usr/lib/python2.7/site-packages/synaptiks/monitors/power.py
<DocScrutinizer05> Written by Werner Almesberger <werner@openmoko.org> -- hehe
<DocScrutinizer05> ta
<wpwrak> power.py is a (very simple) class for power supplies. you could add yours there. the infrastructure gives you communications and "active" variables
<DocScrutinizer05> much appreciated
<wpwrak> yea, these were the old days :)
<wpwrak> the basic idea is that you have a "nice" python interface on top to model your instrument, and C at the bottom to get low-level comms right
<wpwrak> if you look at telnet.c, you'll see what nightmares may await you down there :)
<eintopf> everywhere you will find code written by werner
<eintopf> cool
<wpwrak> eintopf: maybe i should sue poettering for stealing my trademark ;-)
_whitelogger has joined #qi-hardware
<eintopf> wpwrak: you are like "eric s. raymond" for me, I stumble sometimes also much on "eric s. raymond" patches
<eintopf> and then I am "raymoning" again, something like "rickrocklling"
<wpwrak> hmm, i guess that's what i deserve from comparing my style with poettering :)
<eintopf> maybe we should introduce "almesbergering"
<DocScrutinizer05> hmmm >> These libraries are not documented yet, but there is a number of annotated examples in the demo/ directory.<<
<eintopf> everytime you stumble over code by you
<wpwrak> but i have to admit that i'm a happy and very regular user of fetchmail :)
<DocScrutinizer05> don't tell me it's written by poettering
<wpwrak> DocScrutinizer05: yes, i left them out in the "migrated" version (from openmoko). examples are for sissies :)
<wpwrak> (fetchmail) no, by esr
<DocScrutinizer05> I dunno if I want to use stuff that I basically have to read top-down every single line, to understand _how_ to use it. Prolly simpler to fix tty.ko and write stuff myself ;-)
<roh> eeeh.. are you flushing the tty buffers?
<roh> no /n means no automatic buffer flush. when you have so few chars, they are prolly still idling in your fifo :)
<roh> i urge you. do it in python or C. speaking anything not crlf-auto-default linefeeds in shell is breaking your knees madness
<roh> also every > /dev/serialdevice call opens and closes the serial once. some serials 'forget' some details of their config inbetween (bad drivers i guess). so using stty doesnt help
<roh> open, config termios (thats what pyserial does for you then, yay!!1!) then your 'traffic' and close when done is what one wants to do.. to avoid weird drivers/hardware
<DocScrutinizer05> my problem is with \r, NOT with \n
jekhor has joined #qi-hardware
<DocScrutinizer05> and that's the only problem I have, rather it's an inconventience since nothing on linux is ever sending a \r when EOL
<DocScrutinizer05> I don't even see how pyserial would help there
<DocScrutinizer05> still would need the equivalent to talk2controller(){echo -en "$@\r"}
jekhor_ has joined #qi-hardware
<DocScrutinizer05> and I told you even shellscript is capable of keeping a file handle open: eval 5>/dev/ttyUSB 6</dev/ttyUSB
jekhor has quit [Ping timeout: 245 seconds]
<DocScrutinizer05> my problem is that neither minicom nor screen nor any other approach is capable to allow me talking interactively to device, for testing stuff.
<DocScrutinizer05> cat|tr \\n \\r>/dev/ttyUSB0; however should do
<DocScrutinizer05> just it sucks donkeyballs
<DocScrutinizer05> no, it doesn't. Here buffering kicks in
<DocScrutinizer05> obviously tr needs EOF on STDIN to print filtered stuff to STDOUT
<DocScrutinizer05> :-/
jekhor_ has quit [Ping timeout: 272 seconds]
<DocScrutinizer05> while read ...
<roh> *blblbl*
<whitequark> may or may not help
<DocScrutinizer05> whitequark: ta
<DocScrutinizer05> btw prolly smarter than previous version: while read; do echo $REPLY|tr \\n \\r; done >/dev/ttyUSB0;
<DocScrutinizer05> still pissed why stty onlcr doesn't work
<DocScrutinizer05> ok, so much for "improving UI via remote control". The PSU has no switch to conveniently beak output for a short period of time (like 1s or 2). Using power switch is a PITA since it a) takes ages to deplete the primary side buffer caps of SPSU and b) the device runs a full selftest on power-up which again takes 10s or sth
<DocScrutinizer05> however SOUT1 instantly breaks and SOUT0 instantly enables output
<DocScrutinizer05> of course a VOLT060 is also more conventient than fiddling with that incremental turn dial
wolfspraul has quit [Quit: leaving]
pcercuei has joined #qi-hardware
pcercuei has quit [Ping timeout: 240 seconds]
jekhor has joined #qi-hardware
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
wej has joined #qi-hardware
wej_ has quit [Ping timeout: 250 seconds]
jekhor has quit [Ping timeout: 260 seconds]
viric has quit [Remote host closed the connection]
viric has joined #qi-hardware
woakas has joined #qi-hardware