• Future Plans

    Alvi Ahmed11/15/2020 at 19:31 0 comments

      One plan I have is to implement some type of speed control. As can be seen for the demos,     there is no speed control for the RC cars.  

      I would like to try to implement some type of incremental
      speed control in the future, however it will have to be done by
      joystick since I don't have any keyboards that are analog or pressure

      I am planning making separate RC car projects that use different
      wireless communications protocols such as Bluetooth and WiFi.    

      These other protocols may make it easier and simpler to control both cars 

       at the same time as well.   

      For the python script I want to create a GUI and clean up the output

      of the script.  

      I also want to eventually work up to controlling an RC car via a web
      or mobile application.  

  • Testing the Cars

    Alvi Ahmed11/15/2020 at 19:28 0 comments


       As can be seen from the demo above the cars can travel quite a bit of distance
       for small antennas. If I wanted to increase the distance, making the antennas
       longer and supplying the transmitter with 12V would do the trick.  

       The reason why the cars sometimes veer to 1 side is due to the cart wheel at the
       front. An ideal substitute to the cart wheel would be ball casters, however
       since I didn't have any at the time and the cart wheels came with the kit, I
       decided to stick with them. 

       It is also noticeable how many times I over steer the cars, this is
       due to a lack of speed of control. Since I am not using a joy stick
       or an analog / pressure sensitive keyboard, I am not able to control
       the speed therefore the car goes full speed in 1 way or the other at
       the push of a button, I may fix this my implementing a joystick
       controller of some sort.

  • Soldering and Assembly

    Alvi Ahmed11/15/2020 at 19:22 0 comments

    Soldered Boards 

                                            Image of TX board soldered and assembled 

                                             Image of RX boards soldered and assembled

      I am planning to add switches to these boards later on however at the time
      I didn't have any, therefore the only way to turn them on and off was
      to connect/disconnect the battery.  In the case of the TX it is
      powered by plugging in the FTDI232 module.

      For the TX board, I decided to use indicator leds for the states and the
      commands for debugging purposes.  

    Attaching and connecting components on the car 

                                                      Image of RX boards on the cars 

                                                Image of RX boards on the car at different angle

     As seen in the pictures above, the solder RX boards  attached to the chassis of
     with electrical tape, the 2 9V batteries are taped to together and secured at
     the front of the car. 

     The input pins of the L298N are seen attached to the female pins of the RX
     board. The white wires are where the positive of the 9V supply are attached.  

  • Schematics

    Alvi Ahmed11/15/2020 at 19:17 0 comments

                                                            Image of the TX schematic 

      For the TX schematic the main power source is 5V coming from USB via
      the FTDI232 board.  

                                                                  Image of the RX schematic       

      For the RX I have included 9V to 5V converter, I have also included a
      separate 9V for the L298N motor controller.   

      Ideally I would use lithium ion batteries,
      however I would need many more components and features such as battery
      protection and battery charging. Since I didn't have those components
      on hand and didn't want to risk directly connecting lithium ion
      batteries without protection I opted to use the standard 9V batteries
      instead. Simpler and cheaper at the time of making this circuit. 

      Eventually, I will modify my schematic to include the usage of lithium
      ion batteries, especially if I decide to control larger RC cars. 

  • Wireless Test With 2 Receivers

    Alvi Ahmed11/15/2020 at 19:14 0 comments


       As can be seen by the video above, I am able to switch between both
       receivers effortlessly and send the appropriate commands. 

       The reason why multiple LEDS  are lighting up on RX side is because I
       implemented the same states for turning on the motor pins as I have
       done when using the varying PWM duty cycle. 

  • Working with USART and keyboard input

    Alvi Ahmed11/15/2020 at 19:13 0 comments


       As can be seen by the video, when one of the command keys is pressed the  corresponding led lights up and the TX packet sequence changes to the new command. This is the same with changing receivers where only the receiver number in the sequence changes.

       The sequence output is usually much faster, but for the sake of the  demo it was slowed down.

    ** Explanation Below **


       USART by itself would not be enough to send
       reliable data transmissions via 433 MHz modules. Especially to 2
       different receivers. 

       The solution is  to send multiple bytes via USART. One byte for syncing, one
       for the receiver serial number (in this case 1 or 2) and the
       command (front, back, left or right).   

       The TX and RX AVRs both have data buffers that are used to
       store the multiple bytes. When a command is chosen on the TX side,
       the buffer is filled with the sync byte, serial byte and command
       byte. Then sent incrementally via TX interrupt. 

       This is the same with the RX AVR, with the RX data buffer being
       filled up incrementally with received bytes. 

       Initially I did have some trouble using this method, especially with
       making sure the AVR on the RX would read the data in the proper

      To ensure that the data received would be put in the data
       buffer in the right sequence (sync, RX serial number, command), I
       made it so that the RX will only fill up the data buffer if the
       first thing it receives is a sync byte, else reset the RX data
       buffer index to 0 and keep on waiting for the right sequence. 

       While debugging the RX via serial terminal, I have noticed that the
       bytes being received appear in the wrong indexes. This is due to the
       fact that sometimes bytes are sometimes received out of order
       (i.e. command byte read first then stored or serial byte).  

       However, I noticed that whenever a sync byte is the first byte to be received,
       every other byte is in the correct sequence. Therefore that is the
       condition to ensuring a proper data transmission. 

       This may not be the best practice especially if I am planning on
       sending more and more bytes as a packet. Receiving the sync byte
       first may not guarantee that everything else will fall into sequence
       however it is the best solution I have for now. Will develop it more
       later on.

       Also, I am planning on changing the data type sent from char to
       bytes. Char was used purely for debugging purposes. 

       For a char data packet, s represents sync, 1 or 2 represents the
       receiver number and n,f,b,l,r represents neutral, front, back,
       left, and right respectively. This can be seen in the video of the initial test.


       For interfacing the AVR with serial, an FTDI232 board module was used.

       To manage sending commands to TX AVR via keyboard I initially tried
       to use the serial terminal directly by inputting characters
       in it. However,  I have trouble with continuous input, when I hold
       down the button, this does not register in the serial term and treats it
       as 1 press, instead of a continuous press.  

       Therefore I decided to use python and the pyserial and pynput
       modules. This allows me to not only send multiple bytes to serial
       while holding a down button, but also it allows me to input keys
       without having to be in the serial term window due to pynput.  

       Using python...

    Read more »

  • Updates and Changes

    Alvi Ahmed11/15/2020 at 19:08 0 comments

    Multiple changes have been made since I last worked on this project.

    Microcontroller change

       I changed the microcontroller of choice from Attiny85 to
       Atmega328p due to its larger number of I/O. 

    Transmission protocol change

       I chose to use USART for this project. After some research I
       realized that the 433 MHz modules are not reliable enough to send a
       simple data stream such as varying duty cycles. 

       For more reliable data transmission it was essential not only to the
       use USART but also to send multiple bytes via USART to ensure proper
       transmission of data. 

    Using cheap DIY car kits 

       Also I decided to invest in cheap car kits that can be assembled
       instead of trying to make everything out of cardboard.   

    Changing method of input 

       While working with the push buttons I soon realized that they are
       unreliable. I even soldered a "button board" together and have still
       found that the push buttons give false positives or get
       stuck or break easily. Therefore I decided to change the method of input to a
       computer keyboard and send various commands through serial. 

  • Next Steps

    Alvi Ahmed02/23/2019 at 09:10 0 comments

    Since the initial tests shows how jittery the motors are, I believe that  using variable duty cycle as a signal protocol/encoder is not the best option. It may be beneficial next time to try to use a different form of encoding/signal protocol like UART, USART, ICP, SPI, Manchester and etc.

  • Initial Test for Benchmark Performance

    Alvi Ahmed02/23/2019 at 09:06 0 comments

    The goal of these initial tests with prototype cardboard RC car was to gauge how well my setup was regarding the wireless modules, code, circuity and etc. 

    Any changes that I make to any of these will be compared to this benchmark to see if performance has gotten better or worse.

    After reviewing the video, it seems that there are many issues with the car including a lot on inconsistent jittering. The problem is that I am not sure if it is the code at fault or the circuity or both.

    Therefore, the next step will be to take measurements when the car is connected to the transmitting attiny85 and when it is not to see when and where the jittering occurs.

  • Motor Control Using States

    Alvi Ahmed02/23/2019 at 08:52 0 comments

    Now that the receiving attiny85 can differentiate between the different duty cycles and engage the correct state. All that has to be now is to make each state a function and turn on the necessary bits for l298n motor controller.


    To test whether all of this will be enough for a full fledged RC car, it is time to make a prototype RC car and see how well it runs with code and hardware at hand.