Jump to content


Photo
- - - - -

Imaginative uses for DS10A sensors


  • Please log in to reply
61 replies to this topic

#61 etc6849

etc6849

    Cocoonut

  • Registered
  • PipPipPipPip
  • 1706 posts
  • Location:Irmo, SC
  • Experience:average
  • Software:Premise
  • Hardware:Elk M1
  • Tech:X10-RF, Z-Wave, Custom
  • Phone:OBi100/110

Posted 29 April 2010 - 10:31 PM

It looks like you are getting closer. The message below for A should not be: 847B, but 0584 (byte 1 and byte 3). Is the extra nibble for E a typo?

You have: E Closed: C5CA847BC

E should say: Closed: C5CA847B ???

I hope so or something is terribly wrong and this would throw everything else off if you use a FIFO buffer grabbing four bytes at a time. Any result from the W800 must only be 4 bytes as there is no line terminator to use to distinguish the next command; else you could never grab the correct 4 bytes from the ports buffer.

EDIT: However, it appears there is an option to perform error checking and grab the correct data for the next transmission after an error resulting in one too many bytes from the W800. All you need to know is what the correct starting place is to grab the four bytes in the buffer. Since the second byte only shows the complement of the nibble of the first byte, (e.g. C5 CA, note 5 and A are complements, C is repeated), you can use this to get the location of all Byte 1's in a buffer and grab the exact four bytes you need everytime. In addition, you could also perform error checking on byte 3 and throw out the four bytes if it doesn't pass this too.

Note the documentation says:
Byte 1 is device address
Byte 2 lower nibble is complement of Byte 1, upper nibble is Byte 1
Byte 3 is the message code
Byte 4 is complement of Byte 3

The stuff in realterm looks like the raw data and is very similar to the data I posted which I am 100% certain is raw data from the port. The raw data is what you must use if you are using an ascii equivalent, the code will not work. Personally, I think the issue is with the settings of the serial port on the AVR, but I have no idea.

If realterm is working 100% of the time, there should be a way to get the microcontroller to work; it's that simple! However, once you get the realterm stuff figured out, I would consult any AVR forums for help with the AVR part. There are just too many questions I have to begin to help with your issue... How are you talking to the microcontroller inorder to see the data on it's port? Does the program display raw data from the port or an ascii character representation of the data on the port (you can see the difference using realterm if you display ascii + hex)? How do you parse data on the port; a FIFO buffer that grabs 4 bytes at a time? I have no experience with the AVR, so I can't help you anymore than I have :( I know it is 100% possible to do what you are trying to do on a microcontroller though. Be sure to post us some pictures when you get it working though ;)

Edited by etc6849, 29 April 2010 - 10:59 PM.


#62 irkgreen

irkgreen

    Newbie

  • Registered
  • Pip
  • 5 posts

Posted 05 May 2010 - 09:45 PM

I hooked up my w800 to realterm (like hyperterminal but shows hex). The demo software bytes are clearly converted. My data is very similar to yours. For all of my devices (6 of them, A-F)

A
Closed: 050A847B
Open: 050A04FB
B
Closed: 8F80847B
Open: 8F8004FB
C:
Closed: 919E847B
Open: 919E04FB
D
Closed: 838C847B
Open: 838C04FB
E
Closed: C5CA847BC
Open: C5CA04FB
F
Closed: 8B84847B
Open: 8B8404FB

The closed message is clearly 847B and open is 04FB. As you say, those would change with low battery or extended delay (thanks for telling me that actually). The other bytes are the address. Of course, none of these are inverses (which is a shame).

My problem is that when I connect to my AVR, I cannot get these consistently. But I can connect another serial device and get very consistent results. For instance, I sent ABCDABCDABCDABCDABCD in ascii to my AVR via a serial board connected to an ioBridge. Each letter is displayed, consistently.

I'm at a loss.


Wow! D'oh. Turns out I need to pass the W800RF32's signal through a wave-squaring MAX-232 before I can read the signal. Works like a charm now!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users