Breaking News
Newest First | Oldest First | Threaded View
User Rank
Re: Frankenstein's Fix: the Mysterious Data Packet
Stargzer   2/12/2014 1:31:09 PM
I've seen that problem several times over the years, and it's always been a timing problem related to interactions of hardware design and software design.

One occurred when the one side didn't have enough time to process received data before the other side requested to send more, and things ended in a loop where the one side sent an ENQ (Enquiry or request to send data) and the other side only had time to send a WACK (Wait ACKnowledge) before the first side repeated the ENQ, and so on ad infinitum  I don't remember how they fixed that.

A second occurred when a new minicomputer-based (probably all TTL) RJE (Remote Job Entry) terminal kept dropping data. The vendor had their top programmer on site trying to fix it.  You could recognize him by the flannel shirt, blue jeans, and lost look on his face as he travelled between the RJE and a card punch an back, for what seemed like weeks on end.  We were finally asked to come in with a datascope and saw that as soon as the RJE sent the acknowledment for the last block of data, the mainframe shoved another ENQ down its throat, but the RJE didn't see it because it was still processing the last block it received.  It turns out the mainframe programmers had set the mainframe FEP (Front-End Processor) for full duplex, figuring it was faster and more efficient, and both modems were set for constant carrier.  The RJE, however, needed to be set for half duplex because it needed breathing room.  It was fixed when we convinced the system programmers to set the mainframe for half duplex and we reset the modems for switched carrier with a 250 ms turnon time.  With a quarter-second delay the RJE was happy, and so was its programmer!

A third one was also a timing issue, only this time a microprocesser- based barcode reader was stuffing things down the mainframe's throat too fast.  The group in charge of furniture inventory bought this neat little barcode reader to scan barcodes on furniture and sent it to the mainframe all in one fell swoop.  It worked great at the demo at another agency, using a larger IBM mainframe that we had.  On our system the mainframe kept dropping data.  Part of the problem was that the barcode reader blurted out all 64K bytes of data without stopping, and they had set the end of record as a carriage return.  The mainframe was set to sense a carriage return as end of data, and would terminate the read and go on to the next step in its program.  Ours was a slower mainframe, so by the time it got its act together and hung another read up, several records had gone past and into the bit bucket.  Part of the problem was that the application programmer read a record and then went on to process it, including disk access, before reading the next record, which took a lot of time (relative to the datacomm line speed).  It was fixed by changing the barcode reader to terminate each record with a Record Separator (RS) character and not send a carriage return until all 64K had been sent (many teeth were pulled as we interrogated the vendor progammer over the phone).  Then one of our datacomm systems programmers (to whom a macro-assembler was a high-level language) set the mainframe to continuously read data into a gargantuan buffer until it read the final carriage return that terminated the read.  The next step was to split out the records based on the RS character and then pass that list to the remainder of the program. 

"You have to understand how a starship operates."  -- Capt. Kirk, Star Trek: The Wrath of Kahn.


User Rank
Re: Frankenstein's Fix: the Mysterious Data Packet
SandorD   11/20/2013 5:09:31 PM
"...the IOP did not send a 'not ready for data' signal to the laptop"

"This is an example of the software person writing software to get around a

hardware problem."


There are always limits to the capabilities of the hardware, which the

software then needs to take into account and handle correctly.

This case sure sounds like a software problem to me! :-) Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.

Brought to you by:

Most Recent Comments
rick merritt
Like Us on Facebook
Special Video Section
Once the base layer of a design has been taped out, making ...
In this short video we show an LED light demo to ...
The LTC2380-24 is a versatile 24-bit SAR ADC that combines ...
In this short video we show an LED light demo to ...
Wireless Power enables applications where it is difficult ...
LEDs are being used in current luxury model automotive ...
With design sizes expected to increase by 5X through 2020, ...
Linear Technology’s LT8330 and LT8331, two Low Quiescent ...
The quality and reliability of Mill-Max's two-piece ...
LED lighting is an important feature in today’s and future ...
The LT8602 has two high voltage buck regulators with an ...
Silego Technology’s highly versatile Mixed-signal GreenPAK ...
The quality and reliability of Mill-Max's two-piece ...
Why the multicopter? It has every thing in it. 58 of ...
Security is important in all parts of the IoT chain, ...
Infineon explains their philosophy and why the multicopter ...
The LTC4282 Hot SwapTM controller allows a board to be ...
This video highlights the Zynq® UltraScale+™ MPSoC, and sho...
Homeowners may soon be able to store the energy generated ...
The LTC®6363 is a low power, low noise, fully differential ...