
- #Rs ba1 alternative how to
- #Rs ba1 alternative software
- #Rs ba1 alternative code
- #Rs ba1 alternative plus
- #Rs ba1 alternative crack
The interrupt routine processes the transitions from either pin and depending on if it is a high going or low going pulse, and the status of the other line, you get the step and direction of rotation. Works so quickly that you can see the detents. I coded an interrupt driven routine to process the encoder. It goes for around $25, not the best but it works for testing. The only encoder I have around here is a good-quality Grayhill with a detent. I have about every flavor of their STM32F4 and F7 board and this form factor seems to fit my plans. So I ordered another and will try to get ST to replace this one. I've had the board around 2yrs and I guess the flat cable has a crack. Now I'm rethinking this board as the flat cable that wraps around underneath is twitchy.
#Rs ba1 alternative software
The white cable goes to either a PC running RS-BA1 software or the supported Icom radio. Jerry by the way, the second USB is for the integrated debugging. Overall, fun project now that I have it all working. I am using this one for testing and will hope to design some cooler looking buttons consistent with the IC-7610 display. Here's the board with an early keypad overlay from another project. One thing nice about this board is that it presents to a connected PC as a USB drive so for firmware updates, you just take the executable and copy it over.

I am getting pretty good with all this USB stuff though. That is much cleaner, I'll admit, but haven't figured it out.
#Rs ba1 alternative how to
If I can figure out how to enumerate two devices (encoder and keyboard) then I can send the recorded CW and voice buttons directly instead of the extra wire into the accessory jack. I'll use the display for the 10 buttons and wire that into the accessory jack. The encoder will be mounted to the right with three buttons under it. Don't think I'll be using much of that, though. The board itself has all the features we need including 5 leds, SDCard, audio, mics, adc, dac, etc, etc. The display was rubber-glued down and I guess it dried out over the year or so since I bought it. The display itself is no more than 1/32nd thick with a backlight about 3/32nds. The screen is sort of flickering that goes away when I press on the right side where the cable is captured under the display.

#Rs ba1 alternative crack
Only problem with the board is the one I have has developed a crack in the cable or maybe it is just loose. It presents equivalent to an early iphone, has the same look and feel with 680x480 resolution. Here's the STM32F469 development board I am thinking of using. But I have a ton of experience in LCD and TFT screens so this should work out after about 50 compiles or so. The LCQ goes white when I initialize the USB device. Could also be the clock or just be the board I am using as many of the signal lines are dual function. I am hoping it is just related to stack and heap sizes and not some crazy interrupt problem.
#Rs ba1 alternative code
Big bug there as I can't get the USB and LCD code running at the same time, I mean WTF?. Way beyond my scope, I just want a couple more encoder dials (to hang my overweight knob on ) So now onto the LCD design. There's enough horsepower in this board to also embed a CW reader, decoder for digital modes, etc. A slanted 3x5 LCD touch screen with an encoder and knob.

I'm sure I can get over that hurdle but it is their design so unless they publish the USB encoder design requirements in the future, which I doubt, I feel like I would be stealing.
#Rs ba1 alternative plus
The hassles around a commercial product plus fighting with Icom as I reverse engineered their device would take the fun out. Anyway, I realize there is interest in this as us amateurs like to tinker so I am leaning more towards offering this as a QST or QEX project rather than trying to make it commercial. The radio would spin the frequency really fast, hard to even see the numbers, but the RS-BA1 software would just click along in 1.2sec jumps. I must have recompiled, tested and traced my code using Wireshark (thanks again for the that advice) 100 times. Anyway, I got it working so now I can move ahead. Then I had to program the ramping to take advantage of the ramp feature on the radio. So this meant I had to re-architect the code to be two-way (interrupt responding) to this packet as well as pacing my code against the host application ack's coming in. I was replying but about 50ms too slowly. Finally I found a packet coming from the RS-BA1 code that asked for the device firmware level. This drove me crazy as I just couldn't figure it out. Sending my frequency updates to the host code were being paced at 1.2sec vs the radio was just ripping right along. But that is done with the control endpoint (I'm told) and I am using the bulk in/out endpoints.

There is a slight difference in a USB keyboard as the caps lock and other lights are set by the host PC. Remember my base code was originally designed to be one-way as a mouse and keyboard act. Here's an update: I had a heck of a time getting my code to work in two-way mode.
