IR download circuit
- Thread starter cslake
- Start date
Jeremy Leach
Senior Member
I've never tried this, but my rough thoughts for what they're worth are:
<b>1. Comms protocol </b>
With a serial connection there is usually two-way 'handshaking' comms to enable a reliable protocol between sender and receiver. Without two-way communication you would have to ensure the receiving end is listenning before transmission starts.
It's obviously possible to have an IR send (photodiode) and receiver (sensor). Plus it's possible to have two pairs for two way transmission, although there possibly might be issues with reflected signals ?
If the IR path is stable and clear then this could work.
<b> 2. Signal Reliability </b>
IR signal is prone to all sorts of disruption that a simple wire is not. To overcome this you would need to build in error checking. This could be acheived through simple checksums of the databytes being sent. If two-way comms then on error request repeated tranmission. If one-way comms then need to build in 'redundancy' into the data sent - ie send repeated information so that (a certain level of)errors can be corrected without needing to have resent.
I would think that very short transmissions could be ok, but for longer transmissions the risk of corrupted data (or even no data if the IR optical path is blocked) is high.
I'm beginning to think about uses for IR. PicAxes seem to be very powerful in this respect and I think there could be some very useful/novel applications.
<b>1. Comms protocol </b>
With a serial connection there is usually two-way 'handshaking' comms to enable a reliable protocol between sender and receiver. Without two-way communication you would have to ensure the receiving end is listenning before transmission starts.
It's obviously possible to have an IR send (photodiode) and receiver (sensor). Plus it's possible to have two pairs for two way transmission, although there possibly might be issues with reflected signals ?
If the IR path is stable and clear then this could work.
<b> 2. Signal Reliability </b>
IR signal is prone to all sorts of disruption that a simple wire is not. To overcome this you would need to build in error checking. This could be acheived through simple checksums of the databytes being sent. If two-way comms then on error request repeated tranmission. If one-way comms then need to build in 'redundancy' into the data sent - ie send repeated information so that (a certain level of)errors can be corrected without needing to have resent.
I would think that very short transmissions could be ok, but for longer transmissions the risk of corrupted data (or even no data if the IR optical path is blocked) is high.
I'm beginning to think about uses for IR. PicAxes seem to be very powerful in this respect and I think there could be some very useful/novel applications.
hippy
Ex-Staff (retired)
In a controlled environment, for proof of concept and experimenting it should work.
In the wild, the problem is that any IR may be detected as an instruction to the PICAXE to enter its programming mode, which means it could reset and behave quite erratically; it would be similar to leaving the Serial In line floating. In the worst case, the PICAXE could enter the download mode, see something it starts to program, and leave the PICAXE with a corrupt program inside. Recoverable with a reset or another download, but the PICAXE could be 'dead' until then.
Any secondary IR could also play havoc with a genuine download attempt, and bright sunlight could also swamp the signal.
If this mechanism is used anywhere near an IR remote control ( especially IR light dimmers ), you can probably expect lots of problems.
It would be possible to add a switch to disable the IR receiver once download has been completed, and turn it on before each download. That does mean you won't be able to beam a new download into a PICAXE on the otehr side of the room without going over to enable download, but it could be a suitable comprimise.
In the wild, the problem is that any IR may be detected as an instruction to the PICAXE to enter its programming mode, which means it could reset and behave quite erratically; it would be similar to leaving the Serial In line floating. In the worst case, the PICAXE could enter the download mode, see something it starts to program, and leave the PICAXE with a corrupt program inside. Recoverable with a reset or another download, but the PICAXE could be 'dead' until then.
Any secondary IR could also play havoc with a genuine download attempt, and bright sunlight could also swamp the signal.
If this mechanism is used anywhere near an IR remote control ( especially IR light dimmers ), you can probably expect lots of problems.
It would be possible to add a switch to disable the IR receiver once download has been completed, and turn it on before each download. That does mean you won't be able to beam a new download into a PICAXE on the otehr side of the room without going over to enable download, but it could be a suitable comprimise.
Jeremy Leach
Senior Member
Just had another idea following Hippy's comments.
Could have a sort of 'staging' PicAxe that receives the IR data and stores it to memory first. Then this PicAxe serially programs another.
The principle here is that the data could be vetted first in some way to ensure that it's a genuine and uncorrupted download program.
However in practice I think this could be a difficult solution.
Could have a sort of 'staging' PicAxe that receives the IR data and stores it to memory first. Then this PicAxe serially programs another.
The principle here is that the data could be vetted first in some way to ensure that it's a genuine and uncorrupted download program.
However in practice I think this could be a difficult solution.
hippy
Ex-Staff (retired)
That could be done ( I think it was suggested when discussing download over a wireless link ). The problem is in having to know and then emulate the download protocols for the PICAXE which aren't documented or known. There's also the issue of reporting when the Programming Editor is told download was successful ( to the buffer ), when the actual download into the PICAXE fails.
A further issue on the original scheme - What happens if there is more than one PICAXE with an IR download interface ?
That would require a 'smart interface' where each end wraps data sent with an 'address' of where it was being sent to / received from and would again almost certainly, require knowledge of the download protocol.
A straight IR-LED to IR_Photodiode ( or, much better, modulated IR LED to TSOP IR Receiver ) just needs to pass on the high/low state of the line.
A further issue on the original scheme - What happens if there is more than one PICAXE with an IR download interface ?
That would require a 'smart interface' where each end wraps data sent with an 'address' of where it was being sent to / received from and would again almost certainly, require knowledge of the download protocol.
A straight IR-LED to IR_Photodiode ( or, much better, modulated IR LED to TSOP IR Receiver ) just needs to pass on the high/low state of the line.