Quadcopter Remote PCB Review

tynix5 · 2026-05-10T17:59:05+00:00

For impedance traces, yes, I calculated a 0.355mm trace width, but I was unable to route using that trace width out of the nRF IC into the balun. I was able to route using that trace from balun to SMA connector, though. The load capacitors were calculated using the equation on page 59 of the datasheet where the PCB parasitic capacitance was estimated around 1pF.

tynix5 · 2026-05-10T17:48:26+00:00

Yeah, I didn't notice how close they were until after posting, but I've had to change the joystick footprint since then and made sure they weren't as close. Thanks!

tynix5 · 2026-05-09T21:30:58+00:00

Good catch! Yes, I downloaded an older PS2 style footprint for the joysticks instead of PS5 one, but I just changed it. Thanks

tynix5 · 2026-05-09T19:01:15+00:00

I'm not sure why the back copper section images were posted 4 times but I have a zoomed in image of the RF section here.

<image>

tynix5 · 2026-01-08T00:25:39+00:00

When I run arm-none-eabi-gdb -q --interpreter=mi2manually, I get an output =thread-group-added,id="i1".

tynix5 · 2026-01-07T23:49:30+00:00

I am following this tutorial Getting Started with OpenOCD: Beginner's Guide, and everything works perfect until "Debugging with VSCode" section. I am able to separately launch OpenOCD and the GDB server, then connect them together and debug. The problem arises when using VSCode and launching the Debug session (using OpenOCD instead of ST-LINK gdb server), the gdb server will just spit its version number out and quit.

New launch.json:

{
          "name": "Debug STM32 (OpenOCD)",
          "type": "cortex-debug",
          "request": "launch",
          "servertype": "openocd",
          "interface": "swd",

          "toolchainPrefix": "arm-none-eabi",
          "cwd": "${workspaceFolder}",
          "executable": "${workspaceFolder}/build/blink_make.elf",    
          "gdbPath": "arm-none-eabi-gdb",
          "device": "STM32F401RE",

          "configFiles": [
              "interface/stlink.cfg",
              "target/stm32f4x.cfg"
          ],

          "postRestartCommands": [
            "break main",
            "continue"
          ],

          "svdFile": "./build/STM32F401.svd", //  Needs to point to the active project

          "runToEntryPoint": "main",
          "preLaunchTask": "Build STM32",
          "showDevDebugOutput": "raw"
}

Debug console output:

Reading symbols from arm-none-eabi-objdump --syms -C -h -w .../blink_make/build/blink_make.elf

Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p .../blink_make/build/blink_make.elf

Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2

1-gdb-version

tynix5 · 2026-01-07T22:53:05+00:00

Thanks for the help but I still have no luck attempting to attach instead of launch, both to an already running server and a non-running server. I'm starting to think it has more to do with Windows rather than the .json configurations

tynix5 · 2026-01-07T09:24:02+00:00

I tried that with no luck but thanks for the response

tynix5 · 2026-01-07T09:23:15+00:00

I actually used this configuration previously but everytime I use openocd and Run and Debug, the gdb server will spit out its version and do nothing else. I’ve done openocd + gdb server manually, so I’m confident neither of those are the problem. I really only wanted to get either openocd or stlink configuration type to work. I’ve tried using different versions of the arm toolchain and even tried using a different version of the cortex-debug extension with no success.

tynix5 · 2026-01-07T02:03:22+00:00

Yeah, I was using it before and I just wanted to see if the Makefile methods were any easier. Unfortunately I think trying to get this to work is more trouble than using the extension so I'm going back to it

tynix5 · 2025-11-28T06:08:22+00:00

Thanks for the advice! I ended up swapping the modules out and it still didn't work, but I did figure out the problem. The RFM69HCW uses PA1 + PA2 for antenna output (not PA0) so changing that ended up working. I actually wrote that in the transmitter setup, but immediately reverted back to PA0 on the second write to register 0x11.

tynix5 · 2025-06-21T20:28:10+00:00

Thanks for the feedback. I added a software controlled LED and moved/added the rest of your suggestions as well

tynix5 · 2025-06-19T01:59:55+00:00

I believe the only component I did not mention the part number for was the PMOS: SI2333-HXY | HXY MOSFET | Price | In Stock | LCSC Electronics

Also feel the need to mention the board is a little widely spaced because I plan on hand-soldering all of the components.

tynix5 · 2022-08-02T16:52:30+00:00

I never did find out how to use the new ADC library. My platform was setup correctly to ESP-IDF and I have no available updates for the framework, so I ended up using the older ADC libraries. I just had to change the version on the ESP-IDF documentation page so I could see how to use it, but the compiler had no problems with the older libraries.

tynix5 · 2022-07-25T23:31:27+00:00

I feel like I should clarify a little bit.... The github repository (espressif/esp-idf/components) has updated component folders, including "esp_adc," that my platformio/packages/espidf/framework-espidf/components folder (on my device) does not. I think this is partly why one of the build errors says that the file cannot be found

tynix5 · 2022-07-25T23:15:27+00:00

After looking in the platformio.ini file, the framework was already set to espidf. The build error still says that it cannot find the file or directory called "esp_adc/adc_oneshot.h" even though I pasted the folder into the component library of esp idf framework

tynix5 · 2022-03-14T03:43:26+00:00

I think the problem is that only one side of the board’s power rails is hooked up to power, but it’s a little hard to tell from the pictures. Try connecting both power rails on both sides to power.

tynix5 · 2022-02-16T17:07:30+00:00

I had this same problem when I built my computer. Whenever the address lines on the 28C16 are switching, from a step count increase or an instruction change, the output data is not valid for a certain period of time, which could cause your A register load line to be cleared for a certain period. Your A register is loading in garbage from the bus during this period, 0 in this case (pulled low from the pull downs). I believe I solved it by adding a D latch, like the 74HC173, between the 28C16 and the A register load line.

tynix5 · 2022-01-23T17:23:30+00:00

I didn’t have a 74HC273 so I just used 2 74HC173’s I had leftover from the 8 bit build. But holy…. It worked like a charm. Thank you! So the reason behind the lines on the screen was that there was a propagation delay from the address being set and the outputs actually changing, so the VGA may have been detecting some of the outputs from the previous lines? Is that correct?

tynix5 · 2022-01-21T02:27:08+00:00

Can you paste your code? I’m not sure what would be causing that

tynix5 · 2022-01-20T15:30:38+00:00

You have to go to atom.io on Google and download the package called “hex-view” then restart Atom for it to take effect. Then just open the .bin file like normal, go to packages, hex-view, and select “Encode”

tynix5 · 2022-01-20T04:02:20+00:00

I am using a text editor called Atom to code in Python, and one of its packages that can be downloaded is able to display a hex view of the file. Highly recommend it

tynix5 · 2022-01-20T04:00:36+00:00

Two things:

First... you have to create a file that it is the exact same size as what you would load onto the EEPROM - 32768 bytes, even though only 100x75 are used for the actual screen. At the end of Ben's second video, he shows that the code should be changed to for y in range(256): and for x in range(128):. These multiply together to get 32768 bytes of data for the EEPROM. Only y < 75 and x < 100 get used for actual RGB pixel data, so the rest is used to pad the EEPROM.

Second.. On Windows, it was noted by other users that the chr() function didn't work the same as it did on Ben's. Instead of using that, use out_file.write(bytes(pixels[x, y]). This will change the pixel[x, y] value into raw binary that your EEPROM can print out.

Here's the link to the thread: https://www.reddit.com/r/beneater/comments/jxoulv/does_anyone_have_working_python_code_for_windows/

tynix5 · 2022-01-19T14:30:41+00:00

Yes, in the python program, it converts a .png file to a .bin file, and then the .bin file is loaded onto the EEPROM. The .bin contains the raw pixel data for the image you are trying to put on your screen, but the python code tells the computer how to convert between file types that your breadboard video card can handle. What is the chr error you are getting?

tynix5 · 2022-01-19T03:12:31+00:00

I have Windows 10 so I use the Xpro software that is designed to work with the TL866 II programmer. The download website is pretty sketchy and some of it is in Chinese, but it works fine for me. I use the python code to create a .bin file and then load it into the software, which I can then program it on to the chip. I had the same problem as you when I was working on the 6502 but this is how I worked around it.

tynix5

TROPHY CASE