pyserial to read from DS1615 temperature recorder chip
Hi there,
I am trying to use pyserial to read data from a temperature logger
device (T-logger). T-logger is based on the DS1615 temperature recorder
chip (Dallas Semiconductor). According to the DS1615 docs, writing to
the chip is performed one byte at a time. To read from the chip, one
must issue the "read page" command (33h), followed by the two-byte
address of the requested page (pages are 32 bytes long). After
receiving this, the DS1615 will send the data in a burst of (up to) 32
bytes. I can send data to the device, e.g. I can make the device's LED
blink with the test command (44h), but I am unable to read from it.
Connection parameters below are according to DS1615 docs.
>> import serial
>> s = serial.Serial(0, baudrate=9600, bytesize=8, parity='N', stopbits=1,
>> timeout=None)
>> s.write("\x33")
>> s.write("\x00")
>> s.write("\x00")
>> s.read() # "\x00" is returned here. This byte was already in the receive
>> buffer before issueing the write commands.
>> s.read() # The interpreter is blocked here as there is nothing to read
>> from the serial port.
I'm completely clueless and would really appreciate your comments. If
it helps, I can post a log from a serial port monitor captured when the
provided T-logger program pulls data from the device, as well as a log
when pyserial is used. And finally, this is a snippet of some basic
code found on the web, that is suppose to do what I want (untested by
me):
open "COM1:9600,N,8,1,CS0,DS0,CD0,ME,FE" as 1
print #1, chr$(&H33);chr$(&H00);chr$(&H00)
result$ = input$(34, #1)
Many thanks,
alex
--
http://mail.python.org/mailman/listinfo/python-list
Re: pyserial to read from DS1615 temperature recorder chip
Gerhard Fiedler wrote: > On 2006-07-24 14:03:30, [EMAIL PROTECTED] wrote: > > > To read from the chip, one must issue the "read page" command (33h), > > followed by the two-byte address of the requested page (pages are 32 > > bytes long). After receiving this, the DS1615 will send the data in a > > burst of (up to) 32 bytes. > > I'm not sure what you mean when you say it will send "up to" 32 bytes. If > you mean that it sends bytes until all existing values have been sent -- > did you make sure you have any values in the buffer? > > (Just asking the obvious... :) > > Gerhard Thanks Gerhard, Up to 32 bytes means that the chip sends the bytes from the address you give up to the end of the memory page that contains this address. Thus if you give the address of the beginning of a memory page (e.g. like here H for the beginning of the first page, which contains control registers and the current temperature register), you get 32 bytes. alex -- http://mail.python.org/mailman/listinfo/python-list
Re: pyserial to read from DS1615 temperature recorder chip
Thanks Grant, > Can you verify that the device is actually responding by > watching the data line with an oscilloscope? I don't have an oscilloscope but the device does respond (LED blinks) when I send it a test command (44H). > I take it that means that other programs are able to read from > the device? Yes, the device comes with a little GUI program to read the logged temperatures, calibrate, etc... Works fine, but I would like to read distributed loggers over the network with python and sockets. > Logs of the serial traffic would be helpful. Here they are. First a log of the traffic generated by the T-logger GUI program, abtained with Portmon. ### TRAFFIC WHEN THE PROGRAM IS LAUNCHED: 0 0. TLogger.exe IRP_MJ_CREATE Serial0 Options: Open 0 0.6174 SUCCESS 1 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 1 0.0726 SUCCESS 2 0. TLogger.exe IOCTL_SERIAL_PURGE Serial0 Purge: TXABORT RXABORT TXCLEAR RXCLEAR 2 0.0698 SUCCESS 3 0. TLogger.exe IOCTL_SERIAL_SET_TIMEOUTS Serial0 RI:-1 RM:0 RC:0 WM:0 WC:5000 3 0.0168 SUCCESS 4 0. TLogger.exe IOCTL_SERIAL_GET_BAUD_RATE Serial0 4 0.0279 SUCCESS 5 0. TLogger.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial0 5 0.0196 SUCCESS 6 0. TLogger.exe IOCTL_SERIAL_GET_CHARS Serial0 6 0.0223 SUCCESS 7 0. TLogger.exe IOCTL_SERIAL_GET_HANDFLOW Serial0 7 0.0196 SUCCESS 8 0. TLogger.exe IOCTL_SERIAL_GET_BAUD_RATE Serial0 8 0.0196 SUCCESS 9 0. TLogger.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial0 9 0.0168 SUCCESS 10 0. TLogger.exe IOCTL_SERIAL_GET_CHARS Serial0 10 0.0168 SUCCESS 11 0. TLogger.exe IOCTL_SERIAL_GET_HANDFLOW Serial0 11 0.0168 SUCCESS 12 0. TLogger.exe IOCTL_SERIAL_SET_BAUD_RATE Serial0 Rate: 9600 12 0.1285 SUCCESS 13 0. TLogger.exe IOCTL_SERIAL_CLR_RTS Serial0 13 0.0782 SUCCESS 14 0. TLogger.exe IOCTL_SERIAL_SET_DTR Serial0 14 0.0810 SUCCESS 15 0. TLogger.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial0 StopBits: ERROR Parity: NONE WordLength: 8 15 0.0698 SUCCESS 16 0. TLogger.exe IOCTL_SERIAL_SET_CHAR Serial0 EOF:1a ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 16 0.0531 SUCCESS 17 0. TLogger.exe IOCTL_SERIAL_SET_HANDFLOW Serial0 Shake:1 Replace:0 XonLimit:8 XoffLimit:8 17 0.0754 SUCCESS 18 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 18 0.1145 SUCCESS 19 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 19 0.0531 SUCCESS 20 0. TLogger.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 ### TRAFFIC WHEN THE PROGRAM READS CURRENT TEMP FROM DEVICE: 21 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 21 0.1034 SUCCESS 22 0. TLogger.exe IRP_MJ_WRITE Serial0 Length 1: 33 22 0.3269 SUCCESS 20 9.28649032 SUCCESS 23 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 23 0.0587 SUCCESS 24 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 24 0.0559 SUCCESS 25 0. TLogger.exe IOCTL_SERIAL_GET_PROPERTIES Serial0 25 0.0168 SUCCESS 26 0. TLogger.exe IRP_MJ_WRITE Serial0 Length 1: 00 27 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 27 0.0726 SUCCESS 28 0. TLogger.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 26 0.00107611 SUCCESS 28 0.00097666 SUCCESS 29 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 29 0.0587 SUCCESS 30 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 30 0.0503 SUCCESS 31 0. TLogger.exe IOCTL_SERIAL_GET_PROPERTIES Serial0 31 0.0196 SUCCESS 32 0. TLogger.exe IRP_MJ_WRITE Serial0 Length 1: 00 33 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 33 0.0531 SUCCESS 34 0. TLogger.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 32 0.00102583 SUCCESS 34 0.00098811 SUCCESS 35 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 35 0.0559 SUCCESS 36 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 36 0.0726 SUCCESS 37 0. TLogger.exe IOCTL_SERIAL_GET_COMMSTATUS Serial0 37 0.0559 SUCCESS 38 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 38 0.1173 SUCCESS 39 0. TLogger.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 39 0.00934281 SUCCESS 40 0. TLogger.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 Mask: RXCHAR TXEMPTY CTS DSR RLSD BRK ERR RING 40 0.0922 SUCCESS 41 0. TLogger.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 41 0.1034
puzzled by ImageDraw line
Hi there,
I am puzzled by the comportment of the line function from the ImageDraw
module with regard to the way it draws or does not draw the last pixel
of a line.
Below I test this function on a 3x3 image and show schematic
representations of obtained images (where o means a drawn pixel)
import Image, ImageDraw
im = Image.new("L", (3,3))
draw = ImageDraw.Draw(im)
draw.line((0,0,2,2), fill=255)
im.save("test.tif")
Gives:
o--
-o-
---
So the last pixel of the line is not drawn.
Similarly, draw.line((0,2,2,0), fill=255) gives:
---
-o-
o--
And draw.line((1,0,1,2), fill=255) gives:
-o-
-o-
---
But, surprisingly, draw.line((0,1,2,1), fill=255) gives:
---
ooo
---
Where the last pixel of the line -is- drawn, as I expected it would be
for all lines.
This seems to be true for various image sizes and line angles: the last
pixel is never drawn unless the line is horizontal.
Any clues ?
Thanks
alex
--
http://mail.python.org/mailman/listinfo/python-list
Compiling extension with Visual C++ Toolkit Compiler - MSVCR80.dll
Hi there, I am trying to install a Python library with a C extension (the Polygon library) and I am having a bad time. My Python version is Python 2.4.3 - Enthought Edition 1.0.0 (#69, Aug 2 2006, 12:09:59) [MSC v.1310 32 bit (Intel)] on Windows XP Pro. I have dutifully followed the instructions here: http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit i.e., - Installed Microsoft Visual C++ Toolkit Compiler 2003 - Installed Microsoft Platform SDK for Windows Server 2003 R2 - Installed Microsoft .NET Framework SDK, version 1.1 - setup the path, include and lib environment variables with a .bat file, as described in the wiki document The library seems to build correctly (producing Polygon.py and cPolygon.pyd), but when I import it I get the following message from python.exe: "This application has failed to start because MSVCR80.dll was not found". I thought that this might be due to Python trying to link against the .dll from Microsoft Visual C++ Express 2005, also installed on my PC, instead of MSVCR71.dll. So I've removed MS Visual C ++ Express 2005, and any trace of it from my environment variables, but that doesn't seem to change anything. Any help would be greatly appreciated. Regards, alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling extension with Visual C++ Toolkit Compiler - MSVCR80.dll
Thanks for your answers Martin and Peter, I figured out why python.exe was asking for MSVCR80.dll. The first time I compiled the library, MS Visual C++ Express 2005 was used during the build (despite my PATH pointing to MS Visual C++ Toolkit 2003). When I removed Express 2005, I forgot to remove the build directory of my library. I've also had to remove and reinstall the C++ Toolkit, the platform SDK and the .NET Framework SDK and modify msvccompiler.py and my environment variables according to: http://www.vrplumber.com/programming/mstoolkit/index.html but finally it did work. And Peter, your solution worked perfectly. A great alternative to installing all the MS libraries. Cheers, alex -- http://mail.python.org/mailman/listinfo/python-list
SWIG: name 'new_doubleArray' is not defined
Hello,
I am trying to use SWIG (1.3) to wrap some C code in Python (2.3.5)
under Linux, but obviously I am missing something with arrays.
This is my example.c file:
double sum_array(double x[], int size) {
int i;
double sum = 0.0;
for (i=0; i>> import example
But this fails:
>>> a = new_doubleArray(10)
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'new_doubleArray' is not defined
What am I doing wrong ?
Thanks for your help.
alex
--
http://mail.python.org/mailman/listinfo/python-list
recursive map on nested list
Hello, I'd like to apply a function to elements of a nested list and wondered if there is anything more idiomatic and/or shorter than this recursive way: >>> def recur_map(f, data): ... if isinstance(data, list): ... mapped_list = [] ... for i in data: ... mapped_list.append(recur_map(f, i)) ... return mapped_list ... else: ... return f(data) ... >>> recur_map(lambda x: x*2, [[1, 2], 3, 4, [5, 6, [7, 8]]]) [[2, 4], 6, 8, [10, 12, [14, 16]]] Thanks, alex -- http://mail.python.org/mailman/listinfo/python-list
ImageDraw line inconsistent ? (repost)
Hi there,
Sorry to repost this, but I didn't get any answer one month ago. In
essence, it seems that the ImageDraw line function draws lines one
pixel shorter in some circumstances. This could be very annoying for
some applications where precise geometry does matter.
Below I test this function on a 3x3 image and show schematic
representations of obtained images (where o means a drawn pixel)
import Image, ImageDraw
im = Image.new("L", (3,3))
draw = ImageDraw.Draw(im)
draw.line((0,0,2,2), fill=255)
im.tostring()
Gives:
o--
-o-
---
So the last pixel of the line is not drawn.
Similarly, draw.line((0,2,2,0), fill=255) gives:
---
-o-
o--
And draw.line((1,0,1,2), fill=255) gives:
-o-
-o-
---
But, surprisingly, draw.line((0,1,2,1), fill=255) gives:
---
ooo
---
Where the last pixel of the line -is- drawn, as I expected it would be
for all lines.
This seems to be true for various image sizes and line angles: the last
pixel is never drawn unless the line is horizontal.
Any clues ?
Thanks
alex
--
http://mail.python.org/mailman/listinfo/python-list
