455 kHz IR programming cont.

jan h

New Member
Hippy, I notice that you understand much of the picaxe chip. My project IR programming of the chip with a 455kHz IR transmissionline is still under construction but faces a new item. May be you can help me.

If I programma a simple flashing light freq. 2 Hz. Then the request to program the chip is granted after +/- 1 sec or little more. I assume that there is an "logic" explanation for it, but I do not know it. May be you can explain it? However this delay conflicts now with a unkown feature of the TSOP 7000 IR receiver. The IR rec.de-gain itself in 0.6 sec under continues exposure of a IR puls train. Then the output will drop and the programmingsequence is terminated. This last item is communicated with Vishay ( vendor TSOP 7000) but up to now no response is received.
 

hippy

Senior Member
The PC requests that the PICAXE enters its download state by putting its TX line to a permanently high level ( a 'break' signal ) and it keeps the line high until the PICAXE responds or the PC gives up ( "Hardware not found" or similar ). All the time this line is high, continuous IR will be sent out.

The PICAXE has to complete its current command, checks for this 'break' signal, and if present it then enters its download mode. If the command is a PAUSE, NAP, SLEEP or WAIT there can be a considerable delay between issuing a 'break' and it being detected. If the PICAXE is executing a SERIN or INFRAIN it may never complete the command and download mode can only be entered by using the hard reset procedure.

I suspect the problem will be related to this. By the time the PICAXE completes a command, should see the 'break', the IR receiver output has faded away so it never actually gets detected.

One way round this would be to have the IR receiver also feed another PICAXE or some other hardware which can detect that the IR is present for longer than a certain period ( say 0.4 seconds ), ideally forces a reset to the PICAXE being downloaded to, bute essentially here artificially extends the IR receiver output to fill in the 'break' which has faded-out.

The complexity comes in having to have that hardware keep the 'break' signal present for the PICAXE, but not have it interfere with the subsequent downloaded data which will be a much faster toggling data stream which cannot simply be be passed through a PICAXE. One way may be to clear the artificial 'break' as soon as the PICAXE sends some data, after it has seen the 'break', but then it's necessary to ensure that it's not SERTXD or SEROUT data from a user program occuring before the 'break' is actually seen; forcing a reset to the PICAXE removes that problem.

Previous IR programming attempts had not highlighted this problem, so either it was luck then, or the IR output did not fade away after half a second or so. Perhaps you can find an IR receiver which doesn't de-gain, otherwise I think you are going to have to use more complex hardware.
 
Top