2014-10-09 00:36 atommann has joined #qi-hardware 2014-10-09 02:56 viric has quit [Ping timeout: 260 seconds] 2014-10-09 03:00 viric has joined #qi-hardware 2014-10-09 03:56 atommann has quit [Ping timeout: 272 seconds] 2014-10-09 04:08 atommann has joined #qi-hardware 2014-10-09 04:19 kyak has joined #qi-hardware 2014-10-09 04:49 xiangfu has joined #qi-hardware 2014-10-09 04:54 nicksydney has quit [Ping timeout: 244 seconds] 2014-10-09 05:02 nicksydney has joined #qi-hardware 2014-10-09 05:23 xiangfu has quit [Ping timeout: 246 seconds] 2014-10-09 05:24 xiangfu has joined #qi-hardware 2014-10-09 06:17 xiangfu has quit [Ping timeout: 245 seconds] 2014-10-09 06:18 xiangfu has joined #qi-hardware 2014-10-09 06:55 pcercuei has joined #qi-hardware 2014-10-09 07:04 wej_ has joined #qi-hardware 2014-10-09 07:07 wej has quit [Ping timeout: 265 seconds] 2014-10-09 07:35 wolfspraul has joined #qi-hardware 2014-10-09 07:37 jluis has joined #qi-hardware 2014-10-09 08:40 wolfspraul has quit [Ping timeout: 260 seconds] 2014-10-09 08:41 wolfspraul has joined #qi-hardware 2014-10-09 10:04 xiangfu has quit [Ping timeout: 272 seconds] 2014-10-09 10:06 xiangfu has joined #qi-hardware 2014-10-09 10:08 astr has quit [Ping timeout: 272 seconds] 2014-10-09 10:20 astr has joined #qi-hardware 2014-10-09 10:43 astr has quit [Ping timeout: 244 seconds] 2014-10-09 10:48 atommann has quit [Ping timeout: 240 seconds] 2014-10-09 10:56 astr has joined #qi-hardware 2014-10-09 11:12 xiangfu has quit [Ping timeout: 245 seconds] 2014-10-09 11:13 astr has quit [Ping timeout: 245 seconds] 2014-10-09 11:14 xiangfu has joined #qi-hardware 2014-10-09 11:14 xiangfu has quit [Remote host closed the connection] 2014-10-09 11:26 astr has joined #qi-hardware 2014-10-09 11:44 Luke-Jr has quit [Excess Flood] 2014-10-09 11:49 Luke-Jr has joined #qi-hardware 2014-10-09 12:02 atommann has joined #qi-hardware 2014-10-09 13:55 viric has quit [Read error: Connection reset by peer] 2014-10-09 14:03 viric has joined #qi-hardware 2014-10-09 14:05 atommann has quit [Quit: Leaving] 2014-10-09 14:13 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 into a "\r" (e.g. a "cat >/dev/ttyUSB0" simply doesn't work, no matter what I do via stty). Am I suffering some 2014-10-09 14:13 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? 2014-10-09 14:15 in short: what do I need to do so the "\r" in "echo -e GMOD\r >/dev/ttyUSB0" is not needed anymore? 2014-10-09 14:32 jekhor has joined #qi-hardware 2014-10-09 14:41 pcercuei has quit [Ping timeout: 250 seconds] 2014-10-09 15:04 DocScrutinizer05: forget stty and similar pita. (serials termios suck).. take pyserial and hack up a python script 2014-10-09 15:04 also some drivers forget the settings on serial close, so you cannot properly set stuff on shellscripts 2014-10-09 15:05 well, you can, opening tty on evak on fdN 2014-10-09 15:05 eval 4 been there, done that. but it seems stty and/or ioctl of tty doesn't work like supposed to 2014-10-09 15:09 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 2014-10-09 15:11 talk2controller(){echo -en "$@\r"} 2014-10-09 15:11 which is kinda insane 2014-10-09 15:11 tty driver SHOULD handle this 2014-10-09 15:13 I wasted 4 hours trying to talk to that sucker PSU via minicom 2014-10-09 15:14 no luck, probably just because I wasn't able to terminate COMMAND by \r 2014-10-09 15:15 there must be a bug in tty driver since 2007 2014-10-09 15:15 at least 2014-10-09 15:18 but hey, you might be right, I tried to set ourput properties before output channel (fd) been opened 2014-10-09 15:22 nope :-/ 2014-10-09 15:23 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 2014-10-09 15:28 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<< 2014-10-09 15:36 or like this: http://stackoverflow.com/questions/10068886/expect-script-not-sending-new-line-correctly 2014-10-09 15:57 jekhor has quit [Ping timeout: 260 seconds] 2014-10-09 16:09 jekhor has joined #qi-hardware 2014-10-09 16:20 https://www.youtube.com/watch?v=J7K91g8yG_w 2014-10-09 16:30 jekhor has quit [Read error: Connection reset by peer] 2014-10-09 16:33 jekhor has joined #qi-hardware 2014-10-09 16:38 jekhor has quit [Read error: Connection reset by peer] 2014-10-09 16:42 jekhor has joined #qi-hardware 2014-10-09 17:26 viric has quit [Read error: Connection reset by peer] 2014-10-09 17:28 LOL 2014-10-09 17:33 i'm speechless :) 2014-10-09 17:34 viric has joined #qi-hardware 2014-10-09 17:35 every kid's dream :( 2014-10-09 17:49 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. 2014-10-09 17:49 ok, now I know *I* have a problem (=bug), not stty. 2014-10-09 17:49 heh, good timing, eh ? :-) 2014-10-09 17:49 yep 2014-10-09 17:49 echo -e 'GETD\r' >/dev/ttyUSB0 2014-10-09 17:49 works 2014-10-09 17:49 echo -e 'GETD' | tr \n \r >/dev/ttyUSB0 2014-10-09 17:49 doesn't 2014-10-09 17:50 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. 2014-10-09 17:51 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) 2014-10-09 17:53 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 2014-10-09 17:54 viric has quit [Read error: Connection reset by peer] 2014-10-09 17:54 well, whatever 2014-10-09 17:54 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. 2014-10-09 17:54 I'm not able to grok what's going on with \r on my shell 2014-10-09 17:55 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. 2014-10-09 17:55 echo -e 'GETDx\n' | tr x \r >/dev/ttyUSB0 fails 2014-10-09 17:56 you can see with strace what really happens underneath 2014-10-09 17:56 is \r a delimiter that gets handled even in pipes? 2014-10-09 17:56 but it's easier just to write these things in C 2014-10-09 17:56 or what? 2014-10-09 17:58 if you want a library that gives you access to such stuff, you could look here: https://gitorious.org/lab-tools/tmc 2014-10-09 17:58 meh, escaping 2014-10-09 17:58 low-level comms in C, the rest in python. there's also lib/power.py with very simple power supply control 2014-10-09 17:58 saturn:~ # echo -e 'GETDx\n' | tr x \r | od -xa 2014-10-09 17:58 0000000 4547 4454 0a72 000a 2014-10-09 17:58 G E T D r nl nl 2014-10-09 17:59 saturn:~ # echo -e 'GETDx\n' | tr x \\r | od -xa 2014-10-09 17:59 0000000 4547 4454 0a0d 000a 2014-10-09 17:59 G E T D cr nl nl 2014-10-09 17:59 jekhor has quit [Ping timeout: 272 seconds] 2014-10-09 18:01 \o/ I'm not completely braindamaged 2014-10-09 18:01 saturn:~ # echo -e 'GETD\n\n' | tr \\n \\r >/dev/ttyUSB0 2014-10-09 18:01 saturn:~ # 040200000 2014-10-09 18:01 viric has joined #qi-hardware 2014-10-09 18:02 saturn:~ # echo 'GETD' | tr \\n \\r >/dev/ttyUSB0 2014-10-09 18:02 saturn:~ # 040200000 2014-10-09 18:04 alas this still doesn't explain why damn stty reduses to do same like tr does, despite 2014-10-09 18:04 * [-]onlcr 2014-10-09 18:04 translate newline to carriage return-newline 2014-10-09 18:04 suggests it should 2014-10-09 18:05 refuses* 2014-10-09 18:07 saturn:~ # stty -a -opost -olcuc -ocrnl onlcr -onocr onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 2014-10-09 18:09 ((lib/power.py)) sorry what? 2014-10-09 18:11 I find backup-20090831/usr/share/paroli/services/hardware/power.pyo and /usr/lib/python2.7/site-packages/synaptiks/monitors/power.py 2014-10-09 18:12 in https://gitorious.org/lab-tools/tmc 2014-10-09 18:13 Written by Werner Almesberger -- hehe 2014-10-09 18:13 ta 2014-10-09 18:13 power.py is a (very simple) class for power supplies. you could add yours there. the infrastructure gives you communications and "active" variables 2014-10-09 18:13 much appreciated 2014-10-09 18:13 yea, these were the old days :) 2014-10-09 18:14 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 2014-10-09 18:15 if you look at telnet.c, you'll see what nightmares may await you down there :) 2014-10-09 18:16 everywhere you will find code written by werner 2014-10-09 18:16 cool 2014-10-09 18:19 eintopf: maybe i should sue poettering for stealing my trademark ;-) 2014-10-09 18:19 _whitelogger has joined #qi-hardware 2014-10-09 18:23 wpwrak: you are like "eric s. raymond" for me, I stumble sometimes also much on "eric s. raymond" patches 2014-10-09 18:24 and then I am "raymoning" again, something like "rickrocklling" 2014-10-09 18:24 hmm, i guess that's what i deserve from comparing my style with poettering :) 2014-10-09 18:24 maybe we should introduce "almesbergering" 2014-10-09 18:24 hmmm >> These libraries are not documented yet, but there is a number of annotated examples in the demo/ directory.<< 2014-10-09 18:24 everytime you stumble over code by you 2014-10-09 18:25 but i have to admit that i'm a happy and very regular user of fetchmail :) 2014-10-09 18:26 don't tell me it's written by poettering 2014-10-09 18:26 DocScrutinizer05: yes, i left them out in the "migrated" version (from openmoko). examples are for sissies :) 2014-10-09 18:26 (fetchmail) no, by esr 2014-10-09 18:27 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 ;-) 2014-10-09 18:43 eeeh.. are you flushing the tty buffers? 2014-10-09 18:44 no /n means no automatic buffer flush. when you have so few chars, they are prolly still idling in your fifo :) 2014-10-09 18:44 i urge you. do it in python or C. speaking anything not crlf-auto-default linefeeds in shell is breaking your knees madness 2014-10-09 18:45 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 2014-10-09 18:46 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 2014-10-09 18:55 my problem is with \r, NOT with \n 2014-10-09 18:55 jekhor has joined #qi-hardware 2014-10-09 18:56 and that's the only problem I have, rather it's an inconventience since nothing on linux is ever sending a \r when EOL 2014-10-09 18:56 I don't even see how pyserial would help there 2014-10-09 18:57 still would need the equivalent to talk2controller(){echo -en "$@\r"} 2014-10-09 18:58 jekhor_ has joined #qi-hardware 2014-10-09 18:59 and I told you even shellscript is capable of keeping a file handle open: eval 5>/dev/ttyUSB 6 my problem is that neither minicom nor screen nor any other approach is capable to allow me talking interactively to device, for testing stuff. 2014-10-09 19:02 cat|tr \\n \\r>/dev/ttyUSB0; however should do 2014-10-09 19:02 just it sucks donkeyballs 2014-10-09 19:04 no, it doesn't. Here buffering kicks in 2014-10-09 19:07 obviously tr needs EOF on STDIN to print filtered stuff to STDOUT 2014-10-09 19:07 :-/ 2014-10-09 19:07 jekhor_ has quit [Ping timeout: 272 seconds] 2014-10-09 19:07 while read ... 2014-10-09 19:09 *blblbl* 2014-10-09 19:09 DocScrutinizer05: http://www.plunk.org/~grantham/cgi-bin/blog.cgi?id=00015 2014-10-09 19:10 may or may not help 2014-10-09 19:11 http://privatepaste.com/d26dd00abf 2014-10-09 19:19 whitequark: ta 2014-10-09 19:21 btw prolly smarter than previous version: while read; do echo $REPLY|tr \\n \\r; done >/dev/ttyUSB0; 2014-10-09 19:23 still pissed why stty onlcr doesn't work 2014-10-09 19:45 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 2014-10-09 19:46 however SOUT1 instantly breaks and SOUT0 instantly enables output 2014-10-09 19:47 of course a VOLT060 is also more conventient than fiddling with that incremental turn dial 2014-10-09 19:47 wolfspraul has quit [Quit: leaving] 2014-10-09 19:50 pcercuei has joined #qi-hardware 2014-10-09 20:01 pcercuei has quit [Ping timeout: 240 seconds] 2014-10-09 20:09 jekhor has joined #qi-hardware 2014-10-09 20:48 viric has quit [Read error: Connection reset by peer] 2014-10-09 21:28 viric has joined #qi-hardware 2014-10-09 22:06 wej has joined #qi-hardware 2014-10-09 22:06 wej_ has quit [Ping timeout: 250 seconds] 2014-10-09 22:12 jekhor has quit [Ping timeout: 260 seconds] 2014-10-09 22:12 viric has quit [Remote host closed the connection] 2014-10-09 22:32 viric has joined #qi-hardware 2014-10-09 23:14 woakas has joined #qi-hardware