So, going back to this library yielded a very interesting result which makes perfect sense now. If I set the gate length to 5ms (200Hz), I get the same effect as my code above. Meaning, I get a count of how many times the 200Hz counter overflows. So 1400HZ gives me a 7, 1600Hz gives me an 8, and so on. By intentionally losing precision, I don't need to worry about the frequency being exact (which it isn't from the remote.) The difference, of course, is that the counter just runs continuously in the background and always has a ready result for me whenever I want it.
However, it is picking up the noise quite a bit more than my own code and is converting it to valid commands when I just wave the remote around not pushing any buttons. When I do press a button though, it is dead on and never misses.
So I am going to dig into the library a bit and see if I can customize it for my purposes by filtering the noise somehow (maybe only react when it sees the same result more than once) or take what I learn from it and write my own remote library.
The freqcount library is using the internal counter hardware in the Arduino, which I have been wanting to learn some more about, anyway. It is nearly perfect.
In December of 1985 I had to choose between purchasing an Omnibot or a 74 Karmann Ghia. I think we all can guess what choice I made.
I love the Omnibot, but I'd take a different approach to the project.
Th 49MHz band is still reserved for toys and baby monitors, but it is too close to the Ham radio 6 meter band for my comfort. One loose ground on a radio within miles and your band is cluttered. I believe that's the source of your noise.
I'd salvage the joystick and the buttons from the remote's board and build a new board around it. Then you can put it in the 2.4GHz board with an ESP32 on either end and you can make it an ESP32-CAM in the Omnibot and provide a webportal to see what he sees. I'd be sure that both ESP32s had external antenna ports, then I'd hide the antenna inside the robot and the remote so you can keep the original aerials for the look.
Your approach is also awesome and I hope to see the finished project regardless of the path you take with it.
I would never discourage you from doing it this way. I can't wait to see what you come up with.
Given the cost of used ones I'm getting inspired to build one from scratch.
The thing that made Omnibot so unique was the recording function that stored both commands and voice to tape, then repeated them.
The only activity between the pulses is some noise. When the remote is on, that noise is generally pretty low because the remote transmitter overpowers it. But the remote does not transmit anything (other than low level noise) between button presses, no.
There isn't a clear start as in some sort of syncing signal. The remote control is simply audio. It sends audio tones over the remote when a button is pressed (or the audio from a microphone if the talk button is pressed.) The audio signal is shaped inside of the receiver into square waves and then into the CPU.
So when no button is pressed, it is just whatever noise is on the radio output. And it isn't very strong noise, but the integrator used to shape the signals is a single op-amp in high-gain mode, so it amplifies the noise too and every once in a while, the spikes are big enough to be picked up by the fast Arduino as a signal. It probably wasn't as much of a problem for the original CPU because it was slow and it wasn't likely using interrupts because all it did all day is decode tones. If did just that, my original code was working perfectly and the noise wasn't an issue.
I could probably add some hardware filtering on the radio output if the software approach isn't working.
Yep. THAT is specifically the purpose for doing this mod the hard way. In order to retain that function. And of course also to lower the bar for entry since other collectors would only need to remove one IC (the CPU) to completely expand the Omnibot. And reversing it would just require putting the original CPU back into the socket you installed.
Here is the Omnibot CPU pinout if you are interested.
I'm just going to have to challenge myself to build the same function from new components.
I'm very curious about the control encoding to the cassette. The control freqs are in the 49MHz range and the cassette probably had a range 35Hz to 12KHz. Do they filter the original and feed it back to the decoder through the filter, 2 way filtering, or is it converted to something that can be directly interpreted later?
The controls are just audio tones. So the cassette recorder is just recording audio. It doesn't matter if it is control tones or your voice. Just audio.
The 49MHz is called a carrier frequency. The audio is modulated onto this higher frequency (it is using AM modulation) . On the receiver side, it demodulates the audio from the carrier (strips off the carrier and leaves only the audio.) So the tape never sees 49Mhz at all.
These are the control tones:
1400Hz is TALK ON (turns on a relay to connect the radio output to the speaker amplifier)
1600 is FORWARD
1800 is RIGHT
2000 is REVERSE
2200 is LEFT
2400 is TAPE START/STOP (this just turns on a transistor connected to the tape motor to stop or start the motor. You have to have PLAY or RECORD set and then press PAUSE. The TAPE START/STOP is just like unpausing and pausing the tape.)
2600 is SOUND 1 (the sound is generated by the alarm clock)
2800 is SOUND 2 (Also generated by the alarm clock)
4600 is TALK OFF (this is sent when you release the talk button on the remote and switches off the amplifier to the speaker.)
The alarm tones are generated by the alarm clock. The CPU just pulls a line low and that tells the alarm clock to generate a sound to the little buzzer. The Alarm clock can also do it on its own when the alarm goes off.
The Alarm output is OR'd with the CPU TAPE START/STOP output. So either the alarm can start the tape program or a command from the remote can start it. The OR'ing is just diodes.
The Alarm clock is its own circuit powered by an off-the-shelf SIEKO alarm IC. It is powered by the two AA batteries separately from the rest of the robot. So it is running even when the robot is off. If the robot is in timer mode, the alarm can turn on power to the robot by itself and start playing the cassette which has a pre-recorded program. If not in timer mode, the alarm clock just generates a tone by itself like a normal alarm clock until you push a button on the clock.
Ok, so they are converted from the radio input once upon receipt, then interpreted by the chip and sent for recording to the cassette line and it's on the cassette player to record them or not.
So at some point the cassette's output is fed back into the radio pin of the MCU, or is the tape pin reversible?
The radio output goes through one integrator to shape the audio to control tones from the remote. The cassette playback output goes through a separate integrator to shape the pulses from the cassette. For the recording side (which is a separate input to the cassette IC) the cassette is just recording the radio output raw. Whatever you send through the radio is recorded as audio onto the cassette and that might be your voice when you press the walkie talkie button, voice coming in from an external microphone plugged in to the robot, or control tones from the remote if you press a function button. Whatever sequence you do is recorded raw.
The two outputs from the two integrators (playback and radio) are just OR'd together with diodes (because you never ever connect two outputs together directly). This OR'd output goes to the RADIO IN pin on the CPU. So the CPU has no idea if the audio is coming from the cassette player or the remote. All the CPU does is decode the tones thrown at it and set outputs based on which tone it is. It has no more intelligence than that. Really just a radio control decoder.
If it worked exactly as intended, you would not hear the control tones from the tape playback because the relay would be turned off disconnecting the audio from the speaker amplifier. So, recorded voice would only be heard when there was a control tone for TALK which would connect the audio output to the speaker amplifier. But since all of the amplifiers are all in a single chip, there is lots of crosstalk, so you always hear the control tones faintly.
The "TAPE pin" is for controlling the cassette motor. It is an output. It turns the cassette motor on or off. It is not an input from the tape player. There is only one tone input on the CPU (the radio in pin) both playback and radio audio comes into that one pin.
So, something interesting; The TAPE pin output is OR'd with the alarm clock output. So if we use an Arduino, we can switch that pin to an input (when not using it as an output) and we get the signal from the Alarm output to expand on what the robot does when the alarm goes off. And we can also output a signal even when the robot is turned off to turn him on (when the power switch is set to OFF.) Of course that last part would only work if we powered the Arduino directly from the battery (bypassing the power switch) or to its own battery.
That is an elegant solution, given cost and available tech. I think a modern implementation would do well to use harmonics to encode overlapping commands. The singular nature of the recording scheme is visible in their choice of joysticks, in that you can move on only one axis at a time either turning or locomoting.
Have you seen the video series where they restore an Apollo guidance computer?
Nope. I am a hardware engineer in the Aerospace Industry, but that has never bled into my hobby world. My specialty is legacy systems like this, though. I work for a company that sustains support for the old aerospace technology.
My interest is in robotics, animatronics, and just retro technology in general (mainly the 70s and 80s.) Mostly digital and computers, but I also restore and modify old televisions and radios.
I have however worked on very old aircraft computers that used core memory and were less powerful than a calculator. But could still do things like calculate the fuel/air mixture based on the altitude.
So, anyway, I work with technology very similar to the Apollo computer every day.
That's awesome. I never got my foot in the door in that industry. It sounds like you have one of the cooler jobs too.
I'm a private teacher of programming and math. I work one on one with students usually starting at about 7 years old.
For this stuff I'm just a hobbiest with about 35 years of tinkering experience so please forgive me if I ask an obvious question or repeat a question.
My other related hobby is logic design. I'm building a processor from scratch and simulating it in an FPGA network that I built. It's got a lot of bugs to fix but it's currently running 5500Mops at 250MHz doing 128bit math.
I love talking about this stuff. No apologies needed! Hopefully it doesn't annoy others.
For programming, I am almost completely self-taught. My college studies just skimmed the surface of programming just enough for a hardware engineer to need to know. So that was some assembly, some C, and some Visual Basic. All of which I was already at the level of the studies before taking them. So I didn't gain much from that. I am a terrible programmer, but I know dozens of languages now including some obscure ones (like Ada and PL\M). But my brain just doesn't work the way it needs to work for great program writing. When I dive into a programming project, I get into a groove and start thinking correctly, but it soon goes away right after I finish. I am jealous of people that can whip out advanced code like it is nothing.
Diddling in the logic level is really giving me an interesting perspective on programming.
I had to write my own instruction set, assembly language, and a C type language that uses Python type syntax. I haven't made the OOP jump yet, though.
I tried to make the C standard library for it but the Assembly language is radically different and I couldn't figure out how to get the library to utilize all of them properly. I think this is a lack of understanding of the C standard library on my part, but as a solo designer I'm stuck with my skill-sets, such as they are.
I understand that, brother! One of my bright ideas is to install a small 4" B&W CRT in the head of the Omnibot and have it display a virtual face that can emote (like the Cozmo robot). I understand the general idea of it (map a face on a cube and rotate the cube to move the face around. Use nodes and paths on the vectors and manipulate them to change expressions using 3D translations.) But I do not have the skillset to actually implement that. So, Unity on Pi could probably do the heavy lifting. But then I don't really have the skillset to make the 3D models and rigging. Or use Unity. lol. ::
Well, I guess that is the purpose of these projects. To try to learn some new skills!
My specialty is legacy systems like this, though. I work for a company that sustains support for the old aerospace technology.
I am jealous of people that can whip out advanced code like it is nothing.
: