Well I have learned a huge amount about Picaxe in the last 6 weeks, although at times it has driven me to distraction. Since I last reported, I have:
- kept my head down most of the time, after the embarrassing incident of connecting the upper rail MOSFETs to the 5V supply for the Picaxe rather than the 7.xV supply for the motors (apologies again to the very patient @AllyCat and @hippy for the wasted time)
- discovered that I had destroyed one of the upper rail MOSFETs as a result of the above (probably not the first forum member to have smoked a component, as far as I can see)
- added in a battery voltage checker
- added in a current calculator based on a sense resistor (although not yet an interrupt to stop motors in the event of a stall)
- added another of the little OLEDs to display the above
- added a second Picaxe on the receiver side to drive the OLED so as not to slow down the transmission of commands to the motors
- learned how to communicate between Picaxes with Serin/Serout, and how to break down and reconstitute word values for transmission (is it worth making serial comms between Picaxes a bit clearer in the manual - it really focuses on communication with PCs and other devices and it was only really on this forum that I learned how to use it as between Picaxes)
- added a check function to the IRIN/IROUT which seems to have eliminated the rogue signals that sometimes reversed one or other of the motors mid-flight
- discovered the value of using Sertxd as a diagnostic tool to see where the code fails (which happened very many times). Again, would it be useful to explain this in the manual
- learned the value of SYMBOL and a bit of structure: this thread is very useful - https://picaxeforum.co.uk/threads/listing-order-for-bit-byte-and-word-variables-in-code.31860/
The thing that has taken most of the time to work round is the timing of IRIN/IROUT. The length of the timeout on IRIN is critical - too short and it will just miss the transmission and keep cycling round without receiving the command. Perversely, the other big factor is the effect of SerTXD. I had put in lots of them so that I could see what was happening, but of course that meant that less and less was happening because it was getting bogged down. For one test I sent 100 IROUT transmissions in succession, with a SerTXD between each one to show the value transmitted. That took 5.4 seconds - 54ms per cycle. Without SerTXD it took 3 seconds/30ms per cycle. That made all the difference between transmissions being received and not.
I'm quite pleased with the check function. It's not a proper checksum; instead, it looks for a repeat of the same value within a cycle of 3. I had originally allowed for a repeat within 4, but on studying the output from Sertxd it was clear that there was nearly always a repeat within any group of 3. Here's a snippet:
Rich (BB code):
ReadTSOPinputs:
GetLeftIRIN:
ReadLTSOPinput1: ; add "L" in the middle of the label otherwise there is a duplicate label name in the code to get the R motor command
Do until IRINvalue1 < 52
Irin [noparse][[/noparse]100, ReadLTSOPinput2[noparse]][/noparse], TSOPinput1, IRINvalue1; get left motor control signal first. Simpler to say which one we want first, otherwise need an if... loop to allow for right control coming first. Timeout to the second TSOP,
Loop ; now we have first IRIN value, so proceed to get 3 more. do we really need 3 or would 2 be enough
Irin [noparse][[/noparse]75, ReadLTSOPinput2[noparse]][/noparse], TSOPinput1, IRINvalue2;
Irin [noparse][[/noparse]75, ReadLTSOPinput2[noparse]][/noparse], TSOPinput1, IRINvalue3;
[noparse];Irin [75, ReadLTSOPinput2], TSOPinput1, IRINvalue4; [/noparse]
put 500, IRINvalue1, IRINvalue2, IRINvalue3;, IRINvalue4
If IRINvalue1 = IRINvalue2 OR IRINvalue1 = IRINvalue3 then ;OR IRINvalue1 = IRINvalue4 then; checks for a repeat signal. Even if IRINvalues 2 to 4 may be values for R motor, LIRINvalue has to be a L motor value because IRINvalue1 must be less than 52 and one of the others must match it in order to be accepted
Let LIRINvalue = IRINvalue1 ; if it gets a repeat, sets LIRINvalue as the repeated value and goes to get a R signal
goto GetRightIRIN
ElseIf IRINvalue2 < 52 AND IRINvalue2 = IRINvalue3 then; same principle
Let LIRINvalue = IRINvalue2
goto GetRightIRIN
Endif
The output looks like this:
3 LIRINvalues from TSOP1 = 27, 27, 27,
3 LIRINvalues from TSOP2 = 0, 93, 93,
3 RIRINvalues from TSOP1 = 80, 80, 80,
3 RIRINvalues from TSOP2 = 0, 0, 0,
And the winners are: LIRINvalue 27; RIRINvalue 80
Sent via SerialOut: xyz, 22, 0, 22, 0, 0, 0, 7775, [1E], _
3 LIRINvalues from TSOP1 = 27, 27, 27,
3 LIRINvalues from TSOP2 = 0, 80, 80,
3 RIRINvalues from TSOP1 = 84, 84, 84,
3 RIRINvalues from TSOP2 = 0, 0, 0,
And the winners are: LIRINvalue 27; RIRINvalue 84
The SerTXD here is the serial communication of current and voltage to the OLED chip. Hippy had suggested using an 08M2 to handle the IRIN, transmitting the motor commands to the main 28X2 on the receiver side via Serin, but after a certain amount of experimentation I reversed the setup, using the separate Picaxe to run the OLED rather than the IRIN. The reason is that the thing that slows down the transmission of motor codes to the motors is the display, so it seems better to leave IRIN and motor PWM to communicate closely with each other and to minimise lag between them.