Go here, for source code, & additional project detail: github.com/jmharvey1/ESP32BtC... The 2 other videos referenced, in this video, are found here: • Send Morse Code W/ a B... & here: • STM32F103 (BluePill) C...
Thanks Jim. That looks quite useful, having encoding and decoding done by the same device. I'm not a fan of the ESP32, but I can see that having built-in Bluetooth for no extra cost is a good thing for projects like this. In any case, I will be at least studying your source code. Due to the inconsistencies in spacing, some of the code that your decoder is getting clean copy from, I wouldn't be able to copy even if it was slowed down to my current 9 WPM code skill level. And speaking of which, it seems a bit .. unfriendly the way I hear CW being used on the ham bands: a person will send a CQ at 10 WPM, and all of the responses will be between 15 and 20 WPM. Seems to me like the courteous thing to do would be to respond at roughly the speed the CQ was sent, which I guess would mean not responding to CQs if you're not willing to operate at their speed, so I don't know, maybe that justifies it for some. But as a very slow Morse reader, I can see the value of having a digital decoder to deal with that. I mean, copy what I can, and just rely on the decoder for the jackrabbits. And you never know - I might break down and use an ESP32 board. I already have at least one spare LCD module, and I'm curious about some of the dev boards made with the ESP32-C3, which is RISC-V based, making it more interesting to me than the ESP32-S3, which uses a Tensilica core. 73 de AF7VZ
QSL calling CQ, and having a speed demon return the call. That's not supposed to be how it works. But like to think, if the decoder can't copy the returning station, there's no embarrassment in saying, "TU for the call & hope to catch you next time, when conditions are better". The hobby needs more folks calling slow CQs. As for the ESP32, I too ignored it for a long time. (seemed like overkill for most of my projects) But being able to host bluetooth and running RTOS, seemed like a good fit for combining the two sides of Morse code. That (combining the two) proved to be a bigger challenge than expected. Took me several months to get the two play nice, on a single ESP. The problem is how to get usable crash reports (from code you didn't write). But that's another video. Thanks for the comment & hope to hear you calling CQ soon. Jim(KW4KD)
Thanks for the comment. If you're interested in the decoder part. I hope you'll revisit the github site (next week). Should have an update in place that's an improvement over what's shown in this video Jim(KW4KD)
Hi Jim, thanks for this project, iv been hoping to get in to CW for a while and i think this may just give me the push to do so. Please can you explain what i need to change in VScode to make this work with a 2.8 inch screen. I was unable to find any resolution setting for the ILI9341 in user_setup.h, however I've changed the setting in the ILI9341_defines.h and the display resolution has not changed and the text still goes off the screen. Any help would be greatly appreciated.
Steve, Appreciate your interest in the project. And I hope you'll see it through to completion. I know these display's look similar. But this project is built around a 480x320 display. Not a 320x240. The 480x320 allows for 16 lines, @40 characters/line, and 12 horizontal pixels/character. There a similar issue in the vertical direction, with the character height set at 20 pixels. In an earlier iteration of this project I did support both screen resolutions. And you can see evidence of that, in the TFTMsgBox.h file. There, if you comment out line 14, #define HiRes, this part of the code will try to accommodate the lower res screen. But today, that's only a fraction of code, and all the rest of the project makes no allowance, for change in the pixel count. You're welcomed to change the code any way you want, but if your main objective is learning CW, then time wise, I recommend getting the ILI9488 SPI display. That said, I congratulate you for getting as far into the project, as you apparently have. Other things to emphasize: 1. While most any generic Bluetooth keyboard will work, the project is really designed around the Logitech K380. So for the best user experience, that's the one to have. 2. The project is still in active development. So please check the github site regularly (last update was 2 days ago) Again, thanks for the comment, & congrats on your hard work. Jim(KW4KD)
Thanks for the question. If I follow it, there are 5 memories, "F1" through "F5", on it now. Its possible to add more, by following that code. "F1" is intended (setup) to store the call of the station your talking to. And there's a 6th memory for your call (accessed through the "Settings" screen, & sent using the "enter" key). The others are intended for simple "canned" messages. Like "CQ". In my mind, the project is targeted for "ragchew" QSO's, over contesting. So it doesn't have an auto-indexing number memory. Hope that helps. Jim(KW4KD)
Hi Pino Thanks for your interest & question. If you follow the process outlined in the 1st video ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Hb9m60LtSJw.html ,@~the 5 minute mark, the directory references will automatically get corrected to match your local directory structure. The project was originally built on a Linux machine. But today I cloned it, on a Windows 10 machine, (with a totally different directory layout) Also, the process now is even more automatic, than when the referenced video was done. I found as the install process moved along, some error messages appeared, but I just followed the prompts, and they all resolved themselves. BTW, If you're really not that interested in source code, the much faster way to get going is to flash the .bin file to your ESP32. The GitHub site has links to the bin file, and the flash loader. GL & let me know how it works out for you. tnx, Jim(KW4KD) PS: The decoder section is still a work in progress. I at some point I hope to do another video explaining further whats going on under the hood. The general goal is to have a decoder that operates with as little intervention as possible. And final point, the decoder supposedly is optimized for "rag chew" QSO's
@@jmhrvy1947 Thanks Jim for your answer.... now I am going to listen to your video. I am a Linux user and I would like to modify your project to adapt it to my needs...i.e. to make it send decoded chars via Wi-Fi to my PC where I have a GAMBAS3 program that displays chars and also sends code to an IC-7300 via CAT. At present I have a simple Arduino program that sends chars via USB serial connection, but it is quite slow and not so precise. I lack experience with Code and PlatformIO....it seems to me too complex 😞 Best 73 Pino ZP4KFX
"....it seems to me too complex@@pinox61" QSL that. But what I like is how well it (VsCode/PlatformIO) works with a github project. Ideally you will have to do a minimal amount of configuration to get this project up and going (in its current form). Now the changes your proposing sound fairly complex. The unit/project, as it stands, is designed to just plug directly into your 7300's key input, and does wireless keying that way. To be honest, unless there's distance issue, it would seem that linking your blue-tooth keyboard directly your computer would be a quicker/simpler solution. But I probably don't appreciate what all your doing there. Bottom line, good luck, and again, thank you, for taking an interest in the work that's going on here. Jim(KW4KD)
