I'm still working on the Hamster project (in which our intrepid heroine attempts to transmit data from multiple, synchronized sensors over TCP/IP to a desktop computer). I had pretty much succeeded in getting the data streams synchronized this summer, but when we brought everything back to my university and hooked it up in the lab here—no synchronization. Same software, same hardware, but the slower computer revealed some flaws in the code running on the sensors. I have about managed to clean up the code, but still, when you lose one packet, even if it is packet number 38,306 from five and a half hours into a six hour session, it throws the data streams out of synch. The loss of the data is less important than the loss of the synchronization.
There's something in the code that's taking too long. I have to find a way to save a few dozen milliseconds here and there. Even then, some other random factor may turn up and eat one packet out of fifty thousand. But a faster PC might make the problem go away. I think Dr. Science might spring for that.
190 words | October 22, 2004 08:39 PM | Rocket scienceSet your input buffers bigger. That way you won't lose stuff. See setsockopt(m_port, SOL_SOCKET, SO_RCVBUF, (char *) & sz, sizeof(sz)); or the like.
I'll give that a try. Anything that will make more room for the data on the network is worth a shot. At the moment, it looks as if the data aren't getting immediately written out to the socket by the microprocessors and are being overwritten in the microprocessor memory. Which means the packet gets lost before it's even sent.
Posted by: Nee-chama at October 24, 2004 09:29 PMThat still might be helped by the RCVBUF if the microcontroller has to keep the outbound around longer due to the receiver being busy. As you say, it worked with a faster computer. Good luck. Half-baked microcontrollers can be a pain to work with.
Posted by: Derek at October 26, 2004 03:25 PM