Forum Home
Press F1
Thread ID: 65116	2006-01-08 05:45:00	Reading Data from a serial port	paradigim (8637)	Press F1

Post ID	Timestamp	Content	User
419130	2006-01-08 05:45:00	Hi, sorry i am new to doing stuff like reading from a serial device, but i am wondering how to do it, heres my situation: POS computer - poing of sale computer Sercurity camera pc ok so we are redoing our security cameras at our work and we have the cameras goign fine we jsut need to get the cashcam serial data stored on the computer aswell, there is a serial comm cable that we plug into the computer, but i need to work out how i can read data from it, i tried user Hyperterminal but to no avail, the serial data that is sent is such sutff as thetime, and items being scanend at the counter and who is logged in. Does anyone have any idea how i could read the data in? Any help would be graetly appreciated. Here are some version numebrs that might help. I could get task to do it for us but they are rip offs and would charge through the roof for it, i dont no any details about the river details or anything. Thanks program: KT2.04x(GEN)12q tipu version 3.18 log manager: TLM 1.10	paradigim (8637)
419131	2006-01-08 07:10:00	The data stream from the serial device will be in a binary form, encoded according to the equipment makers protocols in all probability. If that protocol is "open source" then you could program to decode it by reading the serial registers, but with commercial applications its unlikely I think. You would end up with probably meaningless data as you could not tell what constituted which portion of each data packet.	godfather (25)
419132	2006-01-08 08:46:00	I would have thought that your POS software would include the necessary programs for saving and reading back the data. Makes it all a bit pointless if you cannot audit your own sales data. I'd have a wee chat with the people who sold you the POS system, you either need the correct manual, or maybe some software is missing or non-functional. Cheers Billy 8-{)	Billy T (70)
419133	2006-01-08 08:48:00	You would require your camera software to be able to record the POS data. This is normally via the input for card 1. Read the instruction manual/help file for your camera software to determine how the POS intergrates with it. This is what you are trying to do isn't it?	berryb (99)
419134	2006-01-08 19:45:00	I would have thought that your POS software would include the necessary programs for saving and reading back the data. Makes it all a bit pointless if you cannot audit your own sales data. I'd have a wee chat with the people who sold you the POS system, you either need the correct manual, or maybe some software is missing or non-functional. Cheers Billy 8-{) He is trying to aviod the people that he brought it off because they charge a rediculos amount to even take a look at the scanner, they wont tell him how to do it h, they only want to do it themselves.	Prescott (11)
419135	2006-01-08 21:54:00	It may be impossible. I did a "behind-the-scenes" interface of an expensive type-setting machine (I'm showing my age.). The communication was encrypted, but luckily using a simple algorithm. You'll need to sort out the communication protocol first. The cable itself may give a clue as the type of hand-shaking, hardware versus software. Instead of Hyper-terminal, you may want to try a product like PCPlus (Procomm), if it still exists. This can be a seriously big hurdle. Next once you're talking to the serial device, you need to figure out what it's saying. Again this can be tricky even for professionals. Basically it involves changing one thing at time, such as UPC code, and trying to reverse engineer it.	kingdragonfly (309)
419136	2006-01-09 02:53:00	Serial communications can be easy . Or very difficult . Hyperterminal is a very poor tool . I often use Conex (a free DOS terminal emulator, with very flexible configuration) . The Microsoft/IBM PC hardware handshake requirements can cause things to just "not work" . The bit rate and DTE/DCE straight/null modem cable difference can delay you . After you have a working RS-232 connection, then comes the real fun: the actual data protocol . That might be simple ASCII . It might be binary (which is fine if you know what it means) . It might be encoded . I suspect you might finish up paying the people with the documentation to do the job . You do want it to work, don't you?	Graham L (2)
1