Suspending asynchronous serial communication to send a single trigger pulse
LutzK
Posts: 7
I am working on a project where the reading of an AD converter is transferred asynchronously via power line communication. A Propeller P1 is handling the input to the power line modem. The data rate is low, just 600 bit/sec.
It works essentially fine using the “FullDuplexSerial.spin” or “jm_hd485.spin” object (for half duplex communication). The problem is now that the communication needs to be interrupted to let a single pulse pass which serves as a trigger for a seismic recorder. Afterwards the transfer of the AD converter readings should resume.
I have used the “stop” function of the serial objects to pause the communication, used some Spin code to generate the trigger pulse and started the serial objects again. This worked also fine.
But since the trigger pulse is rather time critical I tried to replace the Spin code by PASM instructions in a separate Cog. The function of this code is finally to observe one pin of the P1 and send the trigger pulse over the communication pin as soon as the observed pin goes high.
I have noticed now that the communication after a trigger interruption is somehow instable. In a few cases the AD converter readings are transferred but in most cases it doesn’t work or the numbers are disturbed.
The attached short spin file illustrates how I manage the interruption. It uses the programming pins to communicate to simplify the example. But it is my fist trial in PASM and I maybe overlook something essential. The spin file is capable of running but it crashes in the second loop, sometimes already after the first pulse. It behaves somehow erratic.
I would be grateful if someone who has time and is in the mood has a look at the code and give some advice. Maybe there is a possibility to keep the cog of the serial object running during sending the pulse so that not a new cog needs to be started every time after the interruption.
Comments
Why not use 'Simple Serial' instead of starting and stopping a cog? It can easily handle the baudrate described, and if you send the data 1 byte at a time you have an opportunity to pulse or not between each byte.
And it saves a cog for something else...
How wide is the pulse? Maybe you could just send it as a serial character.
-Phil
@R Baggett
Yes, this could probably work. The data transfer is not time critical, just the trigger pulse. I would need to add some kind of timeout feature for the case the connection is broken or the other side not responding since the “Simple Serial” object is blocking the program flow.
@Phil
I was thinking to use 1 millisecond as wide of the pulse, but also a longer pulse would be possible. At the other side of the power line is again a power line modem with a Propeller to receive the pulse. It is just the first edge of the pulse counting for the trigger time. The seismic recorder has a sampling interval of 31.25 microseconds. The repeatability of the trigger transfer should stay at least within one sample interval.
Lutz
The TX is blind. It only blocks until the byte is sent, or more accurately, until the output pin is done going through the motions. if nothing receives it, SimpleSerial don't care. It just wiggles the pin and returns..
BTW, Phil's suggestion is both elegant, and a good warning..
How, for instance would you tell the difference between a pulse, and perhaps the ascii character "0" (Zero)? %00110000
Yes, that is true. I was more looking at the receiving side which behaves blocking while waiting for a byte to receive.
It would be nice to know more details. Do you have to transmit to the device? If not, just use -1 in the TX pin position of the FDS.start() method to disable that pin. If you do, it would be nice to know the timing specifics. You're using true mode which means the idle state of the TX line is high, yet you're using a high pulse to stimulate the device. Can you share device specs or docs?
The power line modem uses high in idle state if there is no data communication. The trigger pulse needs to go down first and then up again. My example ‘PauseTest.spin’ file is not correct in this regard. I was not careful enough while preparing the example.
The project itself consists essentially of the monitoring and the trigger transfer of a seismic borehole source. The source consists of a capacitor bank which is charged with an AC power of 230 V over AC/DC (constant current) converters to 4 x 800 V. If the capacitors are charged fully, i.e. the 800 V are reached, the energy is discharged through two electrodes into the water inside the borehole which produces a spark and successively a seismic pulse. The source is working continuously on an armored cable in depths of a few hundred meters and gives a spark approximately every 30 seconds. The control of the source should not be touched in the current state.
Simultaneously with the spark the source generates a trigger pulse (going from 0 V to 5V and after 10 milliseconds back to 0 V). This pulse needs to be transferred to the surface to trigger a seismic recorder (a seismograph) which is connected to hydrophones in other boreholes. The purpose is to calculate the speed of the seismic waves between the source and the receivers. The seismograph uses a sampling frequency of 32 kHz and the accuracy of the trigger transfer should be around or below one sample interval.
Previously the trigger pulse was sent over a separate pair of wires inside the armored cable, just as a 5 V pulse, but we would like to uses these wires additionally for charging the capacitors in the source in order to transfer more power decreasing the interval between the sparks. Therefore the idea of using a power line modem came up to have data and energy transport on the same wires. The power line modem is of the type TDA5051A and we are using demo boards from https://github.com/DudeYarvie/JARViE_Home_Automation_Modem for testing.
Besides the transfer of the trigger pulse the voltage of the capacitors should be displayed at the surface to have some mean to check if the source in the borehole is working properly.
The communication should be bi-directional. The idea is that the uphole station behaves as master which is sending commands to the downhole station which is answering. We would need a command for polling the voltage value, a command for measuring the propagation delay through the powerline (This is about 240 microseconds but depends on the cable. It can be compensated for.) and a command to change to the trigger mode.
I have attached the spin versions for the downhole and uphole units for illustration. They work so far. The repeatability of the trigger transfer is in the range of 50 microseconds which is almost sufficient. My intension is to get some improvement by replacing the spin code of the trigger transfer functions by PASM.
Just a thought..
Is the trigger to discharge the capacitors some kind of relaxation oscillator, or is the trigger initiated from the downhole processor?
If the trigger is from the downhole processor, the trigger could be timed from the end of some data packet.
The downhole processor fires at a set delay after a serial comm, the uphole processor reports the pulse timed from that same point. That way the time of the pulse is known within the mod/demod jitter of the modem. Can't get any more accurate than that... or much simpler.. with this setup..
If you have a spare pin you might solve the problem with a couple resistors and an NPN or N-FET.
Since any cog holding a pin high will ensure that pin is always high -- regardless of the state of other cogs -- this simple hardware approach gets rid of the serial shut-down/start-up issues that may cause glitches on the line that lead to unpredictable behavior.
OK, so you want to merge a trigger into the coms link, thus freeing wires for better use ?
If you have your own MCUs each end, you can use 9 bit (or even higher) to tag a trigger char as special, so you use the data stream as the trigger indicator.
The time-uncertainty there will be likely mostly modem-defined - a Prop can derive timing down to 12.5ns, I'd expect the modem to be ~1000x worse.
From TDA5051A data, you need highest carrier (148.5 kHz) and data says 600 baud or 1200 baud data with
tsu set-up time of the shaped burst 23/fcr or 1472/fosc s
th hold time of the shaped burst 23/fcr or 1472/fosc s
it also gives
td(dem)(su) demodulation delay set-up time fosc = 8.48 MHz; see Figure 21 - 350 400 μs
td(dem)(h) demodulation delay hold time fosc = 8.48 MHz; see Figure 21 - 420 470 μs
ie indicates a 50us MAX-to-typ range, with no indication of the jitter, but it also says
tc(AGC) AGC time constant fosc = 8.48 MHz; see Figure 5 - 296 - μs
that 296us is less than a single bit time at 600/1200 baud, so an educated guess would have jitter in tpd of (well?) under 50us so you are (hopefully) in the sub-30us ballpark
I'd suggest using a start char of eg 0b000000000 and check if the start or stop edge has least absolute time jitter. I'm guessing stop edge is lower-jitter as that has AGC settled.
If the remote prop has a deterministic reply time, you can measure the round-trip delay to get actual [sw+cable+modem] delays.
What temperature does the down-hole part need to endure ?
The down-hole prop could auto-baud on RCFAST, if you wanted to avoid external oscillator parts. 1200 baud is one part in 16667 at ~20MHz
Thinking on this critical triggering requirement some more, I think you are best to merge the trigger and the coms into a single system.
ie create a time-precise coms link, that can be used for both data and timing.
On a P1, this is not going to be too hard.
I also think you may want to use the RCFAST to avoid needing any external OSC/Xtal parts, on the down the hole end, which will likely be running hot.
Here is one approach, using a 5-bit UART and data packing that allows
~~~~~~~~~~~~~~ 5 bit uart mode, two 'bytes' for 14 bit slots to send 8 bits ~~~~~~~~~~~~~~~~~~~~ (leading data bit is always 1 to give early _/= ) TXL ~~~~\____/====\0000\1111\2222\3333~~~~\____/====\4444\5555\6666\7777~~~~~~~~~~ RXR ~~~~~\\___/====\0000\1111\2222\3333~~~~\____/====\4444\5555\6666\7777~~~~~~~~~~ECHO TXR ^~~~~^ Autobaud span 1 1T [ 16667 @ 1200 Baud & 20MHz ] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ dT Capture span 2 - timing cal 7T ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ TX echo delay 7T [14T = 233333 @ 1200 Baud & 20MHz ] TXR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\_____/====/0000/1111 .... RXL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\\____/====/0000/1111 .... ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ Path delay TpdRr+Tc+(7T+7T)+TpdTr+Tc ? From first TxL edge is (T+7T+7T) = 250000 ticks at 20MHzThe host Prop times from its first TX _/= to the first echo _/= to measure cable delays and modem delays. The uncertainty here should be << your target of 30us
Ancient sampled-UARTS would not be so good for this, as their granularity is based on their sample-times.
For fun, I checked a time-precise coms link on an EFM8LB1 which has a better UART, and tests show the start bit is SysCLK locked, so RI is sysclk locked and with care you can also make TI sysclk locked
P1 can capture and delay to sysclk precision, or ~ 50ns, and the dT capture calibrates for RCFAST variations.
Thank you all for your suggestions and ideas. I finally got the project working. The repeatability of the trigger transfer accuracy is in the range of 5 to 10 microseconds (measured with an oscilloscope) which should be completely sufficient. This might change if there is a load on the power line but this will be checked under real life conditions. The delay of about 240 microseconds caused by the power line communication is measured by sending pings up and down immediately before a trigger pulse and is compensated for.
The following changes to the initial approach were made:
The trigger transfer is handled in PASM by a separate cog.
@JonnyMac
Thank you for emphasizing that a pin which is supposed to be used from different cogs after each other needs to be set to input (which was obvious to me) but also to LOW (which was not obvious to me) after use. I was not aware of the OR relation between the DIRA and OUTA registers of each cog anymore. The idle high state of the pin is realized by the pull-up resistor now. The solution to use a separate trigger pin to force the communication line to go LOW for sending a trigger pulse using a transistor was not needed at the end.
@R Baggett
The trigger pulse downhole comes from an analogue trigger circuit which is connected to a coil around the high voltage cable going to the electrodes of the source. There is also a micro controller to release the shot but this drives a rather big electromechanical switch which causes some delay. So taking the trigger signal from this microcontroller would not be accurate enough.
@jmg
Thank you very much for checking the manual of the power line modem and the thinking work on the jitter of the trigger pulse due to the modem. We use at the moment a 8 MHz crystal, 125 kHz carrier frequency and indeed 600 bit/s. The crystal came with the demo board so we kept it for the beginning.
I don’t think (at least I hope) that we get temperature problems. The boreholes are supposed to be not deeper than 1000 m and the background is not the use of thermal energy. But thank you for the idea to use the P1 without external crystal and the possibility of auto-baud.
And yes, the whole affair is just to save some wires. The armoured logging cables have just 4 wires and it is not easy to change to a bigger cable although there are also ones with 7 wires on the market.
I can imagine the cost of that cable, makes any electronics look cheap !