srmio
=====

srmio is a library to access the most important functions of a Schoberer
Radmesstechnik (SRM) PowerControl V, VI and 7. You can download the data,
mark it deleted, sync the time and set the recording interval. So
hopefully you'll get around booting windows after each exercise. Though it
is not intended as a replacement.

To be as compatible as possible, it's reading (SRM6/SRM7) and writing
(SRM7) files in a the format srmwin uses.


******* !!! USE IT AT YOUR OWN RISK, IT MIGHT HARM YOUR SRM !!!  ****


Please take this warning serious. I've had no docs for the protocol, so I
had to figure it out myself. While I had luck with srmwin bringing
everything back to normal, you might not.

If you just want to use it, please check
 man srmcmd

Please check the comments in the source (start with srmio.h) if you want
to use the lib. srmdump is intended as "simple" example, as well.

Many thanks to Hiroyuki OYAMA who did the real investigation for PC7 and
published his work on https://github.com/oyama/libsrmpc7

build:
======

In most cases:
 ./configure && make 
 make install

On debian you can do:
 fakeroot debian/rules binary
 dpkg --install ../srmio_*.deb

If you use a developer snapshot, you first have use the autotools to build
a configure script:
 sh genautomake.sh

To workaround some design issues with the error reporting, you can build
the lib with support to print some more verbose error messages by defining
the preprocessor variable VERBOSE:
 ./configure CFLAGS="-DVERBOSE"

Driver:
=======

The original USB download cable for the PCV is using a prolific pl2303
based usb-to-serial converter.

Both, PCVI and PC7 have a FTDI based usb-to-serial chip built in.

For now, srmio is relying on the kernel-provided drivers for these USB
chips. It's using the traditional unix termios to access the /dev/tty* or
/dev/cu* devices offered by the kernel.

Though, srmio is now easily extensible to other ways (FTDI D2xx, win32,
...) through the abstraction layer in serio.c.


Linux:
======

- PCV: I've used the original prolific-based USB 2 Serial download cable
  on linux 2.6.27. It shows up as /dev/ttyUSB0 (... or similar).

- PCVI/7: kernel 2.6.32 provided driver for /dev/ttyUSB works.

You can make your life finding the proper device name a lot easier by
letting udev creating meaningful symlinks for you by adding something like
this to a file like "/etc/udev/rules.d/51-local.rules":

 # /dev/prolific for PCV - unfortunately no serial for unique identification
 SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="prolific"
 # /dev/pc7
 SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idProduct}=="POWERCONTROL 7", SYMLINK+="pc7"
 # /dev/pc7, alternative using serial-number
 #SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{serial}=="A2QXXXXX", SYMLINK+="pc7"
 # you can retrieve the serial with "lsusb -v"


Cygwin:
=======

- PCV: Works fine with the original driver from SRM. Shows up as
  /dev/ttyS3 (COM4) or similar. When I've got my first SRM I've had the
  original prolific driver installed for a plain usb2serial cable: I've
  had very bad results with this driver. The issues vanished (for SRM and
  the usb2serial cable) when I've switched to the driver shipped by SRM.

- PCVI/7: Successfully tested with VCP driver (i.e. /dev/ttyS5 / COM6 or
  similar) on Vista. I guess, the VCP driver came from the SRM drivers
  I've installed. D2XX refuses to load ftd2xx.dll if another version was
  loaded, already. Might help to point LD_LIBRARY_PATH to the directory
  with the currently loaded ftd2xx.dll.

I've had problems accessing devices with high COM port numbers. Maybe
cygwin doesn't handle this? In doubts assign a "low" number in Windows'
device manager.


Mac OS X:
=========

- PCV: With the original prolific drivers, starting the communication
  succeeded only occasionally (around 1 of 15 attempts worked). Once the
  communication got established, data transmission worked fine.
  Reconnecting kept working until the PCV had to be woken up, again. First
  waking the PCV up by pushing MODE seemed to improve the success-rate but
  was still very flaky.

 device: /dev/cu.usbserial
 driver: /System/Library/Extensions/ProlificUsbSerial.kext
 kextstat:
  106  0 0x8053e000 0x7000 0x6000 com.prolific.driver.PL2303 (1.2.1) <105 33 12>

 Once we've switched to the drivers from http://osx-pl2303.sourceforge.net/
 all Problems were gone.

 device: /dev/cu.PL2303-* 
 driver: /System/Library/Extensions/osx-pl2303.kext
 kextstat:
  108  0 0x8056a000 0x7000 0x6000 nl.bjaelectronics.driver.PL2303 (1.0.0d1) <107 33 12>

 There's also a driver available from SRM.de. It's reported to work:

 device: /dev/cu.usbserial
 driver: /System/Library/Extensions/ProlificUsbSerial.kext

 If you need to remove the generic prolific driver you can do so by  
 entering the following in a terminal:

 sudo mv /System/Library/Extensions/ProlificUsbSerial.kext ~/Desktop

 This will move the extension to your Desktop so that you can move it back
 later if need be.

 You may need to restart for changes to take effect. After restart verify
 that your device is being recognized by the osx-PL2303 drivers by plugging
 in your download cable and checking the output of

 ls -lrt /dev | tail -n 20

- PCVI/PC7: untested (yet)


Notes:
======

Of course I'm open to all suggestions, comments and patches.

Sorry for my home-brewn "object model" for C, but I didn't want to pay the
GObject price.

If you experience problems with *your* PowerControl, please
 - recompile with -DVERBOSE -DDEBUG enabled. 
   (./configure CFLAGS="-DVERBOSE -DDEBUG")

If you want to help me adding support for your PowerControl, please
capture the communication:
 - if possible, compile srmio with debugging.
 - capture output from 
   srmcmd -v $your_options > srmcmd.out 2>&1
 - download "portmon" from sysinternals
   http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx
 - adjust portmon to log function arguments as hex !!!!!. (Options -> Log Hex)
 - perform same action (download/clear/...) as with srmcmd in srmwin
 - save portmon logfile.
 - send me the resulting files and please describe the problems you
   experience.

For PC VI and 7, there's a free USB sniffer at
http://sourceforge.net/projects/usbsnoop/ and a decoder at
http://www.stillhq.com/usblogdump/

Known Problems:
 - Dates before 1970-1-1 are not supported (SRM uses 1880-1-1 as
   reference). This might lead to problems with bad timestamps or when the
   PC clock is misadjusted.
 - there should be more messages in verbose mode
 - Only writes SRM7 (for now).
 - doesn't use UUCP-Style Lockfiles.
 - result of PC in non-metric display mode is untested.
 - negative temperatures are untested.
 - library interface should have proper documentation
 - for pc7 the data is a little bit different as what srmwin gets. srmwin
   seems to do some smoothing for the elevation. more important: for some
   (random?) chunks srmwin sets power and cadence to zero and I don't see
   anything in the transmitted data, why it's doing this. As a result
   srmwin will report slightly lower work for an exercise.

web: http://www.zuto.de/project/srmio

Rainer Clasen <rc@zuto.de>