Log in

No account? Create an account

Previous Entry | Next Entry

technical people read this

I'm going to lose friends if I keep updating this much. Sorry! But I promise I'll curb it after this one... it's just that I had a brainstorm. See, the biggest think keeping me awake at night about my project is now the software end of things... I'm not a coder and am not familiar with what's out there and might die. But I've got a friends list full of coders and geeks! So maybe someone here can help? Here's the scenario:

Bits are streaming in through a pin on the serial or parallel port or something (baud rate = 2400) (can you stream bits through a pin on the parallel port? I don't even know... that'd work best though)

I need to read those bits.

When the bits fit the pattern '11110000' three times in a row, the next eight bits read will be a temperature reading.

When the bits fit the pattern '01000111' three times in a row, the next eight bits read will be a strain gage (actually there are four gages, each with a unique signature, but that's beside the point)

The data must be read, recorded, and displayed. Since Jaimee's labtop runs windows, that's the OS we're using.

We were going to use LabView but it's all gone downhill, so now I think I might just sit next to an oscilloscope with a pencil. Seriously.

I would give my right arm for a good solution to this problem. I'd love if someone would do it for me, I'd love it even more if someone would show me how to do it myself or at least point me in the direction. I don't have any money, but what I do have I'll give you (uh, like $25 in my paypal account maybe?) Just tell me what language to learn or what software to download or what genius to whore myself to and I'll be there.


( 7 comments — Leave a comment )
Apr. 8th, 2002 01:09 am (UTC)
You can more or less do what you need in most languages through a library at the very least.
I prefer Java so:
http://java.sun.com/products/javacomm/ is the Java communications API. I have never used it but it looks straightforward.
Looks like there's a simple serial port reading example in the user's guide as well, just prints out the bytes of what it gets to the console.
Although this all assumes you're talking in the TTY protocol, so if you say the "bits are streaming in through a pin on the serial or parallel port or something", sounds like you might be scroobied. I would think you will be able to get it to work if you add in the required start and stop bits for the protocol and don't use flow control in the reader.
I'm not too sure of all of this myself, I've never really gotten down and dirty with the serial port.

This might also be helpful for a primer on Serial Port TTY

Good luck!
(Deleted comment)
Apr. 8th, 2002 09:55 am (UTC)
As long as the API supports watching an arbitrary pin, I think that would work very well. All it seems like they have to do is record the incoming data. You could capture it and worry about parsing it later.

My number one concern is fixing the 3:1 junk/data ratio and adding some error checking.
(Deleted comment)
Apr. 8th, 2002 12:37 pm (UTC)
My big issue though is that I'm not sure how to tell the PC when one byte ends and the next one begins. I'll look into the Java thing though, I have ties to java-types in my zip code so that'd be nice.
Apr. 8th, 2002 09:49 am (UTC)
2 things-
1. Your protocol is well, to say things bluntly, retarded. There is no need to send 3 bytes of "hey-i'm-about-to-send-data-of-type-foo" for every 1 byte of actual data.

If you're going to waste bandwidth, waste it on Reed-Solomon error checking. If the transmitter is not very smart, you may want to have it send just one standard data word. If it's corrupted throw out the whole word and re-send.

Say, something like this:

byte 0: temperature
byte 1: strain gauge 0
byte 3: strain gauge 1
byte 4: strain gauge 2
byte 5: strain gauge 3
byte 6: CIRC, with a few bits left over for whatever else you need

2. What are you receiving the 2400 baud stream with? A PC? If so, go to town and use whatever you want. If however you need to be mobile or survive (somewhat) harsh environments, get a PIC. Even better, use a Basic Stamp. You can program them in (eww, yuck, but it's better than PIC assmebly), they can read 2400 baud, and you can have it intelligently *do* stuff with the data, like log it to memory, relay it on to your PC, remember maxes and mins, etc.
Apr. 8th, 2002 12:34 pm (UTC)
Re: 2 things-
Excellent insight, kart, I've been thinking about that a lot myself. The issue before was that the application isn't all that precise so the data wasn't that important to me so I didn't mind wasting 75% of my signal, but there's certianly no need to send that many sync bits in between every character.

I programmed the first PIC (which does A/D conversion and adds in those useless sync patterns) with Basic, it wasn't awful, I just can't work out the protocol in my head of what the one on the other end needs to do.
Apr. 8th, 2002 12:40 pm (UTC)
also must add the totally pointless fact that I've spent four years telling my head professor that reed-solomon was for freaky hippies and no one would use that stupid process. he did some serious government work developing a chip to implement, it's still the fastest available and he's fairly proud of it, so I naturally give him crap about it. It'd be funny if I did anything with any reed-solomon application now, heh, I might do some reading and add it in just for that reason.
Apr. 8th, 2002 02:08 pm (UTC)
Re: reed-solomon
Heheh. Crazy government hippies!

Good luck with the Java data collecting program. If it were a government project you'd probably using Ada instead :-p
( 7 comments — Leave a comment )

Latest Month

May 2018
Powered by LiveJournal.com
Designed by Tiffany Chow