Receiving other IR protocols than Sony - For model railway DCC

edmunds

Senior Member
Dear friends,

As I understand from picaxe manuals and also successful application, picaxe chip happily supports SONY IR protocol. This way up to 127 commands or numbers can be sent and received and that is about what is needed if you have control of both ends - the transmitter and the receiver.

The grass does not look so green anymore, if you need to receive or transmit something other than SONY. In my case, I basically want to receive (and later probably transfer) the so called digital model train DCC signal over infrared. The spec of the signal is easy to find on the internet (example and basics here) and is how the system works over two AC powered rails.

If I understand it correctly, the frequency of the signal is about 11kHz, which is nothing fancy for picaxe. Is there a way to read/send this kind of signal through infrared with picaxe?

If yes - how? pwmout? pulseout?

If no - what other options are there? Is there an IC that can be told to read this kind of signal and report some value back depending on what was read?


Thank you for your time,

Edmunds
 
Last edited by a moderator:

westaust55

Moderator
you can bit-bash your own IR code if necessary.
I posted a basic tutorial on IR comms using the usual 38 kV carrier and SEROUT command prior to the newer IRIN and IROUT commands.
Forum member InglewoodPete also posted code for receiving IR data from another format.

However for your intended application with model railway DCC,
1. the signals for DCC are variable frequency (1's and 0's or different length pulses) so can be from around 8 kHz to 11 kHz depending upon the number of 1's and 0's in the bit stream at a given time.
2. the PICAXE chips even at 64 MHz clock speed are I believe just a bit too slow still to receive the DCC datastream and decode same.

I recall there have been a few other threads on the topic of receiving and decoding model railway DCC signals in the past which reached the same conclusion.

EDIT:
Here are links to a few of the past threads on the PICAXE forum:
DCC type train controller:
http://www.picaxeforum.co.uk/showthread.php?20127-Model-Train-DCC-Controller

Receiving DCC signals:
http://www.picaxeforum.co.uk/showthread.php?11983-How-To-Read-Dcc-Signals-With-Picaxe
DCC timing:
http://www.picaxeforum.co.uk/showthread.php?12200-Model-rail-DCC-timing-20x2-speed
 

inglewoodpete

Senior Member
Receiving other IR protocols than Sony

As I understand from picaxe manuals and also successful application, picaxe chip happily supports SONY IR protocol.
I have created two "universal" IR Receiver designs using a PICAXE. The first one used a CD4093 Schmitt trigger chip to separate the clock and data components of practically any IR signal. The output could then be decoded by any PICAXE at 8MHz or higher. The design was published in Silicon Chip magazine in August 2008.

Later, in 2010, I developed a software-only IR decoder using the newly released PICAXE 20X2. With the 20X2 being able to run at 64MHz, I was able to use hardware interrupts to detect the edges of the IR signal. So the IR signal was received as a background task and then assembled and used in the foreground.

I have not had any experience with DCC or trying to send IR signals with a PICAXE but I'm sure it can be done.
 

Goeytex

Senior Member
Looks like reading the DCC pulses could be done with an X2 Picaxe processor @64 MHz and a "pulse stretcher" IC in the same manner as was done with the DHT-11 sensor.

The incoming low pulse edge triggers a one-shot that is set for a 70us. This is the off time pulse. The remaining time is the on time. The off time is stretched and the on time is reduced. So instead of 61us on and 61us off. The Picaxe will see 70us off and 42us on. 70us is enough time between pulses for the Picaxe using Pulsin to read consecutive 42us pulses into the scratchpad. The data is then processed after the packet is completely received.

This thread may be helpful.
 

hippy

Technical Support
Staff member
The simplest and most cost effective way to to this would seem to be to convert DCC commands into Sony IR commands, then any PICAXE can receive them. While Sony IR is 7-bit data, 8-bit data can be sent using two Sony commands or mapped to a single command and reconstructed when received.

That would probably need two PICAXE X2; one to receive the DCC commands and output serial bytes, the other to background receive those serial bytes and send out Sony IR.
 

westaust55

Moderator
The scheme proposed by Goeytex could work to read a DCC signal.
Certainly reading would likely be more difficult than transmitting.

There would have to be a degree of tolerance away from the NRMA standard
http://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.1_electrical_standards_2006.pdf
as this requires checking of the durations for the high and low part of the 1's and 0's to ensure that the high and low duration for a 1 or 0 are the same +/- 3 usec.

Scanning (Googling) what some home brew PIC based DCC receivers have done, seems that some take a median of 80 usec and if the signal is high at that time it is a 1 otherwise it is a zero.
Would need to synchronise the PICAXE on the falling end of each AC cycle to keep receiving data correctly as a 1 has a nominal total duration (low + high parts) of around 120 usec and a low has a total duration of around 200 usec (but up to 12,000 if a stretched 0).

May have to look at this further myself for accessory decoders for a new under construction layout which has been slowly getting track down ovcer the past 12 months as paying work commitments permit.
 

edmunds

Senior Member
Thank you, guys. On the edge what I can follow and above what I can do something with at the moment, but enough to learn more again :).

Edmunds
 

westaust55

Moderator
A DCC to PICAXE interface concept for DCC decoder

Thinking about using a PICAXE as a model railway DCC decoder, unlike the DHT11 humidity sensor where the starting point is known (immediately after sending a signal out), with DCC there is a need to first receive a min of 10 bits with a “1” state followed by a “0” bit to indicate a successful preamble to a new transmission and we could start detection anywhere is the datastream and must wait for a valid start.

A PICAXE chip even at 64 MHz will not have time to receive bits, and increment a counter to determine whether a successful preamble has been received. I suspect we need to add a little more external hardware as logic IC’s to help get any PICAXE based DCC decoder across the line. Interrupts will not help as the PICAXE must complete the current command then in effect do a GOSUB so it could be of the order of 100 usec before we could detect the signal start by which time a “1” bit duration is virtually finished.

A thought I have had is to use the pulse stretching scheme as posted for DHT11 humidity sensory by forum members Goeytex and MGU but add some external shift registers (eg 74HC164 = 8-bit shift register without latch) and some 74HC00 series AND/NAND gate logic (74HC30 = 8-input NAND gate and 74HC11 triple 3-input AND) plus an inverter gate or two to detect a minimum of 10 “1” bits plus a ‘”0” bit to signal to the PICAXE its time to start reading in bits for the address, instruction and error_checking bytes. Use 2 cascaded 74HC164’s creating a 16-bit shift register but only need to detect 11 bits (10 x “1”s with 1 x “0” as last received bit as valid preamble.
Put the DCC signal straight to the shift register data_in pin and used the stretched transition for the clock pin.

Once the PICAXE knows a valid preamble has been received, we can either record pulse durations for the next 27 bits of data (as per the Goeytex/MGU example for the DHT11 sensors) or at a stretch see whether the PICAXE is fast enough at 64 MHz to input bits and save the “1” and “0” states directly.
It may even be possible (????) to use the same shift register to present whole bytes to the PICAXE as 8-bit parallel data but need to consider that the 9th bit is a “0” after the address and instruction bytes and a “1” after the error check byte.

Suggest also make sure that you are using ultrafast diodes UF4002 or 1N914 for any bridge rectifier for the DCC signal as these are better to use with the high frequency DCC lines rather than 1N400x series diode which are slower to “turn off” and better suited to mains frequency applications.

I do not have a lot of spare time at the moment to go too far with this concept, but longer term a working solution will also benefit me so will try to put some time into this.
Attached is a concept schematic based upon my above idea to detect a valid preamble. This circuit is completely untested at this time.
As the last bit is a zero (Packet start bit), the signal to the PICAXE will transition high to low 80 usec into the duration of the "0" bit and there will be around 120 usec for the PICAXE to get ready for 27 further data bits.


If my quick maths are correct, then using the PULSIN command to get duraitons for the bit data, at 64 MHz and a 555 set to 78 usec (4k7 resistor and 15 nF capacitor)
a "1" will have a PULSIN value of 40 to 80 covering the DCC tolerance range
a "0" will have a PULSIN value from ~160 to around 19,300 in the case of a stretched "0" (up to 12 msec)


A few further things to be considered:
1. Depending upon the connnctions of the DCC decoder to the DCC rails/bus, the availabale signal may be inverted so a pulse stretcher scheme then triggers on the second half of the waveform and data timing will be out. This will not be apparent until there is a "1" to "0" transition (and vice versa)where the PICAXE PULSIN command will have resulting values in the range 100 to 150 - so this can be used to alarm a need to swap the incoming DCC wires.
2. When there is a stretched "0" we will have values exceeding 255 hence need to handle these correctly. PULSIN <pin>, @ptrinc will only save the lower byte and could lead to an erroneous state witht he stretched "0" being set as a "1". Thus need to receive into a word variable and save the two bytes to the scraptchpad. THIS MAY BE THE ASPECT THAT PREVENTS USE OF A PICAXE EVEN AT 64 MHz as we now need 3 commands instead of 1.

While the above &#8211; a DCC decoder/detector is only one&#8211;half of what Edmunds is ultimately looking for it will be a start and there has been several past threads where folks have contemplated using a PICAXE for a DCC decoder.
 

Attachments

Last edited:

inglewoodpete

Senior Member
Dave, That was 4 years ago! I have a Hantek DSO-2150-USB Oscilloscope (2008 Vintage) connected to my PC. The IR receiver module was connected as per the diagram on the IRIN command in Manual 2 (Commands), although I was obviously not using the IRIN command.

The oscilloscope was connected to the wire between the IR module and the PICAXE and triggered on the falling edge of the IR signal (Yellow trace). The signal in the green trace was created by code in the PICAXE itself, output to another PIN: Slightly different software for each diagnostic trace/picture.

I added text and arrows etc to each screenshot JPEG image using Windows "Paint" (if I recall correctly).

You can do (almost) anything with a PICAXE:)
 

westaust55

Moderator
PICAXE DCC decoder - an update

I finally squeezed in a bit of time to look at the possibility of decoding DCC model railway signals with a PICAXE microcontroller over the last 2 evenings.

Further to the information I provided at post 8 above, I realised that a 555 timer as a form of pulse stretcher will not work. We need a fixed duration pulse as a reference point giving the PICAXE time to set up between each pulse read in the Pulse generation period. A 555 will remain low with a DCC &#8220;0&#8221; bit low period so we are forced to use a 74HC223 (non-retriggerable so better if available) or 74HC123 (retriggerable but does work).

So far I cobbled up the 74HC based front end and connected a 20X2 PICAXE and can detect a valid preamble plus start bit then read in the 27 following bits (as 1 byte, 1 start bit, 1 byte, 1 start bit, 1 byte, 1 stop bit) using the PULSIN command.


Keep in mind that this PICAXE based scheme is only measuring the duration of nominally the second part of the bit pulses, and does not look at the signal levels and thus while working is NOT NMRA compliant as we do not verify the duration of both the low and high parts of each bit nor do a rigourous check on signal durations. My current code does include some checking for pulse durations that are out of spec.

Once I get something more extensive testing in terms of a basic PICAXE front end program code, I will try to provide a new post on using the PICAXE to decode model railway DCC signals.

The attached rough schematic does give the basis of the DCC to PICAXE front end as assembled to date.

Based on the front end circuit and a 20X2 running at 64 MHz watching the idle signal on an NCE Power Pro DCC booster

a DCC "1" results in a PULSIN value of 56 to 64 (= ~ 35 to 40 usec)
a DCC "0" results in a PULSIN value of 216 to 221 (= ~ 135 to 138 usec)

When we add the 80 usec duration of the monostable pulses
a "1" bit has a total duration of around 80+ ~38 = 118 usec [ NMRA is nominal duration of 116 us +/-6 usec per bit half]
a "0" bit has a total duration of around 80+ ~136 = 216 usec [NMRA is nominal duration of 200 usec with -5 usec per half and + many usec for second high half]
so we are within the range for use and decoding.
 

Attachments

Last edited:

westaust55

Moderator
PICAXE DCC decoder - a further update

Some further testing over the last few evenings reveals that the circuit in the attachment to post 11 is seemingly the ideal solution.

I have tried detecting the original/raw DCC signals as “1” and “0” states on receipt of a valid preamble signal and find that even with some “tweaking” of the timing for the fixed duration pulses that DCC packet bits are lost or incorrectly detected (mainly seeing 0's where 1's expected).

Also tried deleting the 74HC30 and instead using the second half of the 74HC21 with a total of 5 signals into the PICAXE 20X2 for detecting a valid preamble.
Seems that there is the slightest increase in time to detect the interrupt with 5 bits to be validated than with a single input pin and again the finding was that the first bit is lost frequently.

So the way forwards for now is using the circuit as attached to post 11.

I believe that the best solution is going to be using one PICAXE to receive the DCC data packets and then transfer the data to a second PICAXE to complete the decoding and undertake the required actions.
Looking at the timing with a single PICAXE, doing bit manipulations to extract the 3 bytes of data and displaying this via SERTXD to the PE Terminal one only received about 2 data packets per second (partly due to SERTXD time albeit at 76,800 baud) whereas some modified code with little processing is achieving around 80 data packets per second – which equates to every second DCC data packet successfully received.
Thus if the first PICAXE does nothing but collecting the data and making it available may be able to do better than only receiving every second DCC packet.

Clearly it will not be a “pretty” circuit with 6 x 74HC chips and two PICAXE chips but if I get it working could be less cost than most commercial decoders and hopefully far more flexible with basically whatever output actions the end user desires performed by the second PICAXE.

I have identified the code structure for the basic 3 byte data packets based upon the NCE cab handset input commands (other makes apparently use different schemes for user interface – the NCE hides some complexities from the user) so I know how to determine the byte values when a required command has been put on the DCC bus.

More another day, but it will take at least some weeks (if ever fully successful) before there is something definite to post as a DCC tutorial for PICAXE based decoders.
 

westaust55

Moderator
PICAXE DCC decoder - a further update

Some further information as &#8220;Seen&#8221; when monitoring DCC data packets from an NCE Power House/Pro DCC system with my prototype PICAXE based decoder hardware.

1. Packets for mobile/locomotive decoders are repeated regularly and forever with the latest values &#8211; as could be expected to keep control of a train the runs across an insulated point frogs or section of dirty track causing momentary loss of contact with the rails and loss of DCC signal. Even lifting a loco off the track and putting it back on the track a minute or maybe hour later and it will resume at the last control settings.
2. Packets for stationary/Accessory decoders are sent only a few times in relatively succession &#8211; a stationary/accessory decoder should not lose contact with the DCC signal but under the NMRA standards can miss 1 following packet. So at least the NCE (and no doubt others) send the same data several times. There is reasoning behind that also in so far as we do not want to keep sending the command to set points/signals in one direction/position (which is a different packet address/pair structure) only to have another packet sent later to revert to the previous position.

What I see when the system is idle is that the accessory decoder packets are sent at least 4 time (and if I am only receiving roughly every second packet that could be at least 8 times in consecutive packets or in alternate packets 4 time such that at best I see 4 consecutive packets for the same accessory decoder.

When loco decoder information is also present, then the accessory encoder packets are interspersed with some locomotive data packets and maybe some idle packets and the end result at present is that sometime I may see several accessory decoder packets,, sometimes only 1 accessory data packets and unfortunately (horror of horrors :eek: ) sometime my existing code completely misses the accessory decoder packet.

My existing code has a primary PICAXE 20X2 receiving the data packets and doing limited math to combine into several bytes of data for a second PICAXE to further fetch via i2c comms, then decode and action.
Seems that my code is still missing too many DCC data packets, so will investigate moving most of the remaining maths to the second PICAXE chips for some further experiments over coming evenings.
The fundamental hardware and PICAXE interrupt driven receiving code works well and I see virtually no bad packets &#8211; just not getting back fast enough to fetch subsequent packets.
 
Last edited:

westaust55

Moderator
Success for a PICAXE based DCC Accessory decoder for Model Railways

I have finally had some far better success with receiving and decoding model railway DCC data/command packets.

As per some of my posts on the PICAXE forum, mainly under this thread, using a combination of:
- a hardware front end comprising 6 x 74HC series IC's,
- one PICAXE 20X2 running at 64MHz to receive the DCC packets as 27 discrete values from the PULSIN command, and
- a second PICAXE 20X2 running at 64MHz to complete the decoding process and currently display some data about the data packets

The first mentioned PICAXE 20X2 collects 4 consecutive DCC data packets, makes a small start at assembling 2 out of 12 bytes for the 4 DCC data packets and then signals the second PICAXE to fetch the data and continue while the first chip receives the next 4 data packets. This first chips does not miss any DCC data/command packets but is limited to 3 byte packets as used for basic Accessory Decoders.

The second 20X2 fetches the received data from the first PICAXE 2-X2 via the i2c bus and then completes the assembly back into bytes for the data packets together with checks for serious timing errors and bad data. Then if not an idle packet currently displays the information - in an extended format for accessory packets so folks can see what is happening..

Even at 64 MHz, the second PICAXE 20X2 only has time to decode 3 out of the 4 received data packets and still leave a little time for other future tasks.
My current demo which sends out serial data with the SERTXD command at 76,800 baud slows the process down and only two valid accessory decoder packets have their information displayed before going to get the next 4 DCC data/command packets.

Observation is that I still see every accessory command I send from 1 to 3 times depending on how much text I try to serially send to a PC terminal for checking. Therefore missing the odd DCC data packet should not be a problem.

Timing in all parts is very critical (down to microseconds) and I have avoided subroutines. I have structured the program to be as fast as possible even at 64 MHz as in many parts there is only a few spare milliseconds remaining for timing variance or the end user's final control of some outputs. Not using serial output will give time to undertake some actions in the end users final application.

Edmunds has indicated through PM that he may be willing to undertake some testing to verify the scheme will work on other systems.

In the mean time I am going to investigate possible use of an overclocked 28X2 as the second PICAXE (maybe at 72 MHz or 80 MHz) &#8211; I recall reading hippy has run a PICAXE at 100 MHz which would give a little more spare time for undertaking the end users actions such as controlling a bank of outputs (for points, semaphore signals, or as I envisage in the future, for building lighting control).
While a clock speed increase does help, there are limits due to comms bus speeds. For example running the second PICAXE at 32 MHz it took around 7ms to copy over around 100 bytes from scratchpad to scratchpad via i2c whereas increasing the clock speed to 64 MHz only reduced that time to around 5 ms -but every millisecond counts in this project. Other commands do increase in speed more proportional to the clock speed.

I will also look towards (slowly) preparing something of a tutorial/getting started article with schematics and program code to help others achieve a similar project.

EDIT: found where hippy ran a 28X2 at 100 MHz: http://www.picaxeforum.co.uk/showthread.php?17369-New-28X2-64-Mhz-at-5v-is-this-real
 
Last edited:

westaust55

Moderator
I have sent the schematic and program files to Edmunds on Saturday for testing using other makes of DCC control system.

On Monday I tried a 28X2 in place of the 20X2 for the second PICAXE. Then increased the speed to 72 MHz (using an 18 MHz crystal with 18 pF ceramic capacitors).
With the i2c and HSEROUT parameters recalculated for 72 MHz all is working and that reduces the time to transfer the data from PICAXE #1 to PICAXE #2 by around 30% or 1.5 milliseconds. At 72 MHz all was stable for over an hour.

While I have made an initial trial at 80 MHz. The PICAXE 28X2 rang okay but could not get the i2c comms to run correctly with many bad packets so more investigations required there.

In the meantime, attached is a simplified timing diagram showing the salient points and timing between the DCC data, PICAXE #1 and PICAXE #2 for collecting and decoding the DCC data packets in sets of 4 packets each comprising 3 bytes. You will have to expand the pdf in a viewer to something like 200% for good readability.


EDIT:
Got the PICAXE comms for the i2c working properly tonight.
I believe I having the parameter i2cFAST_80 set at 24 is optimal (compared with i2cFAST_72 at 22) and the time to transfer data from PICAXE #1 to PICAXE #2 is the same as at 72 MHz being ~2.9 ms. The overall routine to decode 3 packets without acting upon those packets has improved and there is ~10.5 ms at 80MHz of spare time (versus 9.4 ms when at 72 MHz).

I did find that over the course of an hour as I gradually increased the i2c comms speed that I was also having to increase the parameter for the HSEROUT baud rate (from 260 up to 273 going up about 1 counts for each 2 count reduction in the i2cFAST parameter).
Will be doing some further testing tomorrow night . . . .
 

Attachments

Last edited:

Mad Mart Uk

New Member
Awaiting further progress, as this project looks very interesting - I am looking forward to this becoming a reality, as I have a load of Model Rail projects in mind.
Similar to you; I will be initially interested in an addressable decoder for a light signal system :cool:
 

westaust55

Moderator
My decoder is working - currently as a demo switching various LED's on and off.
I have started a write up and should post in a new thread in Finished Projects area shortly - maybe within a week.
Edmunds is going to test with a different make of DCC controller (mine is NCE) but he was awaiting some 74HCxxx chips for the front end.

I started to assemble a further DCC decoder over last couple of evenings.
Pre test with same component values found the pulse from 74HC123 are about 60 Usec instead of about 80 usec. That just may be the IC but more likely to tolerance for the 10 nF ceramic capacitor.
Will be trying changing out both -one at a time tonight and see which is the source of deviation.
 

Circuit

Senior Member
I am following this work with great interest. Please be encouraged with your most fascinating work; I am sure that many others are following this likewise. DCC to PICAXE can really open some interesting doors for railway model-makers.
 

westaust55

Moderator
I decided to get busy and have now created a new thread in the Finished Project area for my PICAXE based DCC accessory decoder project.
See here for details uploaded over the past couple of days:
http://www.picaxeforum.co.uk/showthread.php?27439-PICAXE-based-DCC-Accessory-Decoder


Once Edmunds (who has now received the 74HCxxx chip needed) has had a chance to assemble a circuit and test with his alternate makes of DCC command systems we will have a better idea on the versatility of my project.
 
Top