EEVblog Electronics Community Forum
Electronics => RF, Microwave, Ham Radio => Topic started by: cncjerry on March 15, 2018, 02:11:03 am
-
Hello,
ICOM makes a small device that attaches to either a computer or ICOM radio called an RC-28. It can be used to tune the sub receiver on an ic-7610 for instance. It costs a little north of $200.
I've coded mouse and keyboard drivers on an STM32F4 board, pretty easy, and I was thinking if I had the enumeration for the device and/or other driver info, I would be able to build an encoder driver that would attach to the radio instead of the RC-28 using some of the STM32F4 boards I have here.
They ship a DLL with it as it can also attach directly to a PC. Anyone know how to decompile the DLL to see what is going on? In that way if I get my encoder working with a PC you would think it would work with the radio.
Thoughts?
Thanks
Jerry
-
You're not alone in wanting to clone the RC-28. I've always figured it was nothing more then a mouse with a unique VID and PID. I was surprised it needed a firmware update to work properly with the IC-7610. The Griffin Powermate seems like a cheap alternative if it could be made to work.
-
Steve, what bugs me about the mouse on the 7610 is that in CW, you can click on a signal but then you need to take your hand off the mouse to finish tuning. I don't know why they can't use the freakin wheel? I mean, how hard is it? I think the reason they don't want to support the mouse wheel is that then cheap bozos like me would be able to code up a mouse program using an encoder and dupe the rc-28. I've been playing around, and you can almost tune by holding the left click and moving the mouse. I say almost as it is twitchy.
I'm probably going to purchase the Rc-28 and scope it to see what codes it's using. Even at that point, though I am stuck with the device, I could play around and build other control systems for the radio. By the way, it's a bear to code a program to do simple things. I wrote some code in VB 2017 community and I am working my way through the roughly 1000 commands. Again, I'm sure I'll purchase their remote control software, this is just for my own edification.
Back to the RC-28, I searched everywhere for code. All I have is the HIDxxx.dll (can't remember the actual name).
Thanks,
Jerry
-
I considered buying one but don't think I'd get enough use out of it. I have an Icom 7800 which has no need for an external second VFO(it's built in). I do use RS-BA1 but so far I only use it for working digital modes such as FT8(worked Tahiti on 20 meters 30 minutes ago using it).
Maybe you can extract the firmware from the update they released not too long ago.
-
I saw a firmware update, downloaded it and it executes as an exe file. I'll take a look at it. If they used a PIC as the internal processor then maybe I can do something with it.
How do you like the 7800? You haven't had it that long, have you? I thought I saw where you picked it up a few months ago?
Jerry
-
I saw a firmware update, downloaded it and it executes as an exe file. I'll take a look at it. If they used a PIC as the internal processor then maybe I can do something with it.
How do you like the 7800? You haven't had it that long, have you? I thought I saw where you picked it up a few months ago?
Jerry
Had an IC-7600 for several years and always enjoyed it. With the 7610 being released the price of the 7800's are finally coming down. Made an offer on one already located in Canada and the seller accepted after a bit. Original owner, all docs/manuals/box etc with it. So far I absolutely love it. If I have one complaint it is that the LCD is showing its age. There was a slightly updated model of the original 7800 released in Europe though so when I get the service manual for it I will see what Icom updated the LCD with. I also considered a 7610 but this was cheaper by a decent margin and just something I always wanted. The fit and finish is well above my 7600. It is also lacking a direct USB interface like the 7600/7610 has but the RS-BA1 software handles that nicely for me using a network connection which is preferred to USB anyway(it is isolated).
-
The 7800 is a killer radio. I looked around, couldn't find out at a reasonable price, then tried for the TS-990 and that fell through. So I bought the 7610. Seems like a great radio.
-
Are there any news about cloning rc-28?
-
You can download a trial version of Binary Ninja or IDA to have a look at what the library is doing and it may be even easier if done with C# you can identify the compiler with DIE Do It Easy it will also show what if any type of obfuscation is in the library. Both of those decompilers add human readable English to the assembler output for people that haven't worked with registers. It may have a secondary device driver with it to access a port on a Ring 0 privilege but I cant see an Icom library being to hard to poke at. Almost every thing written in C# can be decompiled back into actual source code using .NET Reflector and its as easy as clicking a button with reflector type programs.
Cheers
-
I finally broke down and bought an rc-28. This will give me some ideas as to how this is coded (e.g. VID, PID, etc). I've coded some mouse drivers with stm32f4 and F7 boards. I'll post here if I make progress. I would love to be able to write a simple driver for a $15 STM discovery board that would interface with a standard rotary encoder. The RC-28, though well built, etc is way over priced for a rotary USB device with two buttons.
Jerry
-
Rc-28 came today. It uses a VID 0c26 but the device id is not as below which is registered. That must be old.
Prolific Technology Inc. 0018 USB-Serial Controller [Icom Inc. OPC-478UC]
So now I have to figure out how to trace the USB port. I see events on the system using the event manager so maybe I can dig through there unless there is an easier way? I know it has a serial number that would need to be sent to the host as well.
So I have my work cut out for me.
Any hints on how to make this easier? I thought about just tracing the data lines using a logic analyzer or my DSO. I could just open it up and see what chip they are using as well. Maybe it isn't protected?
Thanks
Jerry
-
Can it be opened easily - and if so does it happen to use serial data between a USB chip and a microcontroller?
I am sure it is a glorified mouse, it wouldn't make any sense for them to use anything else.
-
When I plug it into the PC, it is enumerated as a USB Input Device:
USB\VID_0C26&PID_001E&REV_0001
I know very little about USB but I was able to program an STM32F4 board to act as a mouse. So I assume there is a data structure setup that is passed to the PC as a reply to some inbound request. I am searching through Tilen's (STM32F4discovery.net) examples, those which I've used in the past, to see if there is a data structure I need to populate differently then when I created the mouse. If I find the data structure, then I should be able to get the driver loaded. Then I have to translate and reply to the request for a serial number. I should be able to just send reports to the PC. Reports are what describe the mouse movement, keyboards keys, etc.
Sounds simple, eh? I figure a $15 STM32 discovery board and an encoder would be cheaper than a $200 rotary encoder. I need a couple of these things.
So, I am digging around.
Jerry
-
I found the data structure where the VID and PID are coded and I am going to recompile and test. There could be some secret sauce I'm missing but one step at a time. Worst case is I hook up the logic analyzer and decode the stream.
The RC-28 adds a ton of function to both the 7610 as well as the RS-BA1 software. Having a low cost version is clearly worth the effort.
-
so I have my code working as a mouse again and then started modifying it to match the RC-28. I have the VID, PID, Class and subclass all correct. I have everything I can see except the Serial number string and that gets into the path string as well, correct. But of course it isn't working. It could also be the report I am sending to the PC. Remember, you send reports to the PC that contain the data from the device. There is a code, could be anything, but I want to get the serial number string working first. I don't know how that is created. In my example code, the serial number is a summation of three hex ids opposed to a text string.
This is a lengthy learning process. I was reading USB data flows last night. What I need is a way to trace the USB data flows. I was looking at the event viewer last night but couldn't get it working.
Thoughts?
-
ok, I resolved how to get the serial number into the device descriptor. I have the VID, PID, Class, subclass and now serial number string all reporting correctly to the PC. Now I have to trace the device to see what the differences are. MS has an event tracer, somewhat difficult to use as there is a lot of data you have to sort through.
When I start ICOM's RS-BA1 software and look at the USB device drop down, I don't see the device I'm creating. This can mean about anything. The software could be looking for a sub-subclass that isn't exposed, for example.
Anyway, still digging.
Jerry
-
There is a Linux (and I think perhaps other platforms) library to allow the use of the Hercules DJ controllers for SDR. They can be found fairly cheap (~$50) used and they have multiple control surfaces including two large encoder knobs, the simulated CD platters, as well as many other knobs which likely can be used for other controls.
-
ok, major progress tonight. I found a tool, tdd.exe that dumps the USB interface descriptor. I have a bunch of errors in my descriptor but easily fixed as they are just a sequence of bytes. This tool will be very handy for debugging USB enumeration issues.
Anyway, I was trying to use the MS Message Analyzer which reportedly you can use for tracing usb data flows but I had a problem with the surface hub I am using.
I expect by tomorrow I should have the STM32F767 board recognized by the Icom remote control program. Then I should be able to just send it reports with encoder positions. There are also three buttons on it and it looks like they use the standard mouse descriptor for them.
My intent with the 767 touchscreen is to use it for programmable buttons the trigger both CW and Voice recordings on the 7610 as well as interface with the remote encoder for the sub receiver. This will make a nice package, not cheap, but high function.
More to come...
-
Maybe you already know but you can use wireshark to capture USB traffic: https://wiki.wireshark.org/CaptureSetup/USB
-
thanks for the wireshark link.
I have a basic problem with my code I guess. I started out with a mouse end point device which is a one way transfer. The HID I need is two way. So in modifying the device descriptor I had to add an "out" endpoint, which I did. This changed all the structure lengths but I have the device descriptor looking perfect except it isn't reading the string descriptor table correctly. It could be an alignment issue, I don't know, I've been staring at it all I morning. I dont even see how the string table is defined in this code as it is all macros. The other issue is the report descriptor is wrong as I was using the mouse report descriptor (so it would be wrong).
The real issue is that all this is new to me. The guy that wrote this base code is really good with stm32Fx boards on stm32f4-discovery.net. I think he has a generic HID driver that should have two end points instead of just this mouse code. Maybe I have to go back to basics.
I thought once I got the device descriptors correct I would be flying but no, of course not.
I need someone that knows stm32f4 boards and USB devices to lean in here.
Thanks for reading along.
Jerry
-
Hi Jerry,
I'm far from an expert in USB communication but I've reverse engineered the odd USB device and Wireshark was helpful. I too experimented with HID devices but that was on the PIC platform, and what I remember is that it is not really intuitive with the device descriptors, the endpoints an such. I wonder why you say that you need a two way transfer, do you mean the pc is going to send data to the device? If it is a mouse-like HID what would that data be, does it use polling or something like that?
Unfortunately I have no experience with stm32 devices so I can't offer any assistance there but I'm following your quest ;)
Paul
-
Yes, the device does two way with the PC or radio. I assume it is just to turn on the lights.
Take a look at the good device descriptor first and then mine second. You'll see that the string descriptor table is not being read correctly. Doesn't make sense as it was working a while back but as I started to make changes to my device descriptor table, it started presenting this error. I've checked it a bunch of times, can't find anything wrong with it. I looked at it in debug and setting aside the two bytes per character for unicode, it is fine. I then moved it in the sequence the device sends to the PC and there was no difference. Also, the PC sees the right data from my device as the serial and mfgr data is correct.
The error I get during enumeration is:
This device cannot start. (Code 10)
STATUS_DEVICE_DATA_ERROR
The good data from a real RC-28:
_________________________________________________________________________________________
Information for device Icom RC-28 REMOTE ENCODER (VID=0x0C26 PID=0x001E):
Connection Information:
------------------------------
Device current bus speed: FullSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x001A
Current configuration value: 0x01
Number of open pipes: 2
Device Descriptor:
------------------------------
0x12 bLength
0x01 bDescriptorType
0x0200 bcdUSB
0x00 bDeviceClass
0x00 bDeviceSubClass
0x00 bDeviceProtocol
0x08 bMaxPacketSize0 (8 bytes)
0x0C26 idVendor
0x001E idProduct
0x0001 bcdDevice
0x01 iManufacturer "Icom Inc."
0x02 iProduct "Icom RC-28 REMOTE ENCODER"
0x03 iSerialNumber "RC-28 0102074"
0x01 bNumConfigurations
Configuration Descriptor:
------------------------------
0x09 bLength
0x02 bDescriptorType
0x0029 wTotalLength (41 bytes)
0x01 bNumInterfaces
0x01 bConfigurationValue
0x00 iConfiguration
0xC0 bmAttributes (Self-powered Device)
0x32 bMaxPower (100 mA)
Interface Descriptor:
------------------------------
0x09 cbLength
0x04 bDescriptorType
0x00 bInterfaceNumber
0x00 bAlternateSetting
0x02 bNumEndPoints
0x03 bInterfaceClass (Human Interface Device Class)
0x01 bInterfaceSubClass
0x00 bInterfaceProtocol
0x02 iInterface "Icom RC-28 REMOTE ENCODER"
HID Descriptor:
------------------------------
0x09 bLength
0x21 bDescriptorType
0x0111 bcdHID
0x00 bCountryCode
0x01 bNumDescriptors
0x22 bDescriptorType (Report descriptor)
0x002D bDescriptorLength
Endpoint Descriptor:
------------------------------
0x07 bLength
0x05 bDescriptorType
0x81 bEndpointAddress (IN endpoint 1)
0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (1 x 64 bytes)
0x01 bInterval (1 frames)
Endpoint Descriptor:
------------------------------
0x07 bLength
0x05 bDescriptorType
0x01 bEndpointAddress (OUT endpoint 1)
0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (1 x 64 bytes)
0x01 bInterval (1 frames)
Microsoft OS Descriptor is not available. Error code: 0x0000001F
String Descriptor Table
--------------------------------
Index LANGID String
0x00 0x0000 0x0409
0x01 0x0409 "Icom Inc."
0x02 0x0409 "Icom RC-28 REMOTE ENCODER"
0x03 0x0409 "RC-28 0102074"
------------------------------
Connection path for device:
USB xHCI Compliant Host Controller
Root Hub
Generic USB Hub
Icom RC-28 REMOTE ENCODER (VID=0x0C26 PID=0x001E) Port: 4
Running on: Windows 10 or greater
Brought to you by TDD v2.11.0, Mar 26 2018, 09:54:50
___________________________________________________________________________________________________
and then the data from my device:
_________________________________________________________________________________________
Information for device USB\Vendor_0C26_Product_001E:
Connection Information:
------------------------------
Device current bus speed: FullSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x0010
Current configuration value: 0x01
Number of open pipes: 2
Device Descriptor:
------------------------------
0x12 bLength
0x01 bDescriptorType
0x0200 bcdUSB
0x00 bDeviceClass
0x00 bDeviceSubClass
0x00 bDeviceProtocol
0x08 bMaxPacketSize0 (8 bytes)
0x0C26 idVendor
0x001E idProduct
0x0001 bcdDevice
0x01 iManufacturer
0x02 iProduct
0x03 iSerialNumber
0x01 bNumConfigurations
Configuration Descriptor:
------------------------------
0x09 bLength
0x02 bDescriptorType
0x0029 wTotalLength (41 bytes)
0x01 bNumInterfaces
0x01 bConfigurationValue
0x00 iConfiguration
0xC0 bmAttributes (Self-powered Device)
0x32 bMaxPower (100 mA)
Interface Descriptor:
------------------------------
0x09 bLength
0x04 bDescriptorType
0x00 bInterfaceNumber
0x00 bAlternateSetting
0x02 bNumEndPoints
0x03 bInterfaceClass (Human Interface Device Class)
0x01 bInterfaceSubClass
0x00 bInterfaceProtocol
0x02 iInterface
HID Descriptor:
------------------------------
0x09 bLength
0x21 bDescriptorType
0x0111 bcdHID
0x00 bCountryCode
0x01 bNumDescriptors
0x22 bDescriptorType (Report descriptor)
0x002D bDescriptorLength
Endpoint Descriptor:
------------------------------
0x07 bLength
0x05 bDescriptorType
0x81 bEndpointAddress (IN endpoint 1)
0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (1 x 64 bytes)
0x01 v bInterval (1 frames)
Endpoint Descriptor:
------------------------------
0x07 bLength
0x05 bDescriptorType
0x01 bEndpointAddress (OUT endpoint 1)
0x03 bmAttributes (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040 wMaxPacketSize (1 x 64 bytes)
0x01 bInterval (1 frames)
Microsoft OS Descriptor is not available. Error code: 0x0000001F
String Descriptor Table
--------------------------------
Index LANGID String
0x00 0x0000
0x01 0x0000 Request failed with 0x0000001F
0x02 0x0000 Request failed with 0x0000001F
0x03 0x0000 Request failed with 0x0000001F
------------------------------
Connection path for device:
USB xHCI Compliant Host Controller
Root Hub
Generic USB Hub
USB\Vendor_0C26_Product_001E Port: 2
Running on: Windows 10 or greater
Brought to you by TDD v2.11.0, Mar 26 2018, 09:54:50
_________________________________________________________________________________________
I'm not giving up but running out of ideas. The issue could be the string descriptor maybe varies by device descriptor. Most of this is published but in volumes of data.
Ideas?
thanks
Jerry
-
wireshark is pretty darn cool. really easy to use.
According to it, my string descriptor is contained in a malformed packet. This confirms what the TDD.exe is telling me. I used that to dump the descriptors. But now I don't know why. I didn't mess with that code. Also, the packet has no semblance of correctness at all. I would have thought I would see some of the bytes. So this must have something to do with the Unicode process that builds the string descriptor. Maybe something to do with alignment as all the arrays are byte, word or double word aligned.
Anyway, this keeps me on the current track.
Jerry
-
Well, I'm sure there is more than one icom owner reading this thread... waiting... can he do it? Save me $200 on a rotary encoder???
Ha, success! I'll admit to coding micros for 42yrs but all this USB stuff is new to me. So this is a yuuuge accomplishment for me. Wireshark and Tdd.exe were key, so thank you.
I don't know what I am going to do yet with the code. My vision is an STM32F767 with touch screen and rotary encoder. The touch screen is for external buttons that activate the prerecorded CW and voice files on the radio. Used with the RS-BA1 software on a PC the button combinations are endless but the real need is the encoder as the RS-BA1 software is tough to tune without it, unless you find the key combinations which I found yesterday, finally.
Anyway, I have the RS-BA1 recognizing my HID device and responding to my reports to move the tuning dial. Now I have to code up the encoder and buttons which is easy considering all these structures that had to be coded for USB enumeration.
Now I have to figure out if: 1) I make a product; 2) publish in QST or QEX; 3) Just say heck with it and keep it for myself. Not to sound like a jerk it's just that I've found some of the people on the icom forums to be really against hacks, mods, etc. I point to all the flack I took by mentioning that I made a slightly heavier knob for my radio. Then the poor guy that made the heatsink clips for the ADCs, you would have thought he painted over the Mona Lisa with a roller! That's the reason I haven't mentioned this on that forum.
For a low cost encoder, I can pick up an STM32f4 disco board for like $15 plus a high quality encoder for about 25 and for less than $50, have pretty much all the important functionality of the RC28 which is over $225 in the states (unless you buy from Japan off ebay).
Anyway, thanks for the help. I'll post as I move along and build the encoder enclosure and touch screen. You might remember I have a complete CNC shop in my basement so I want to make sure the encoder is heavy, solid, and smooth turning.
Jerry
-
Jerry, a huge congratulations!
I know the group you speak of and a few people there really do get worked up over silly things, especially mods.
I do hope you share the information, either publicly or privately but do understand if you don't.
I can't wait to see what you build. I had always thought modifying a Griffin Powermate would be a nice affordable option(no idea what it uses internally though for a MCU).
-
This is great work, and if you publish your work or make a product, you will be a hero to many. It's the essence of "amateur" radio.
Don't worry about the haters who seem to think tinkering with their gear is some sin against Lord Icom.
-
Well done! I've been subscribed to this thread and reading every update. Incredible bit of work you have done there.
Myself and I'm sure a few others would love to build one.
Look forward to reading further updates as you progress.
-
Wow, great achievement. It would be nice to have free info available to build one. Even if you decide to keep it for yourself, still amazing job :clap: :clap: :clap:
Roberto EB4EQA
www.rbarrios.com (http://www.rbarrios.com)
-
here's an update:
I had a heck of a time getting my code to work in two-way mode. Remember my base code was originally designed to be one-way as a mouse and keyboard act. There is a slight difference in a USB keyboard as the caps lock and other lights are set by the host PC. But that is done with the control endpoint (I'm told) and I am using the bulk in/out endpoints. Sending my frequency updates to the host code were being paced at 1.2sec vs the radio was just ripping right along. This drove me crazy as I just couldn't figure it out. Finally I found a packet coming from the RS-BA1 code that asked for the device firmware level. I was replying but about 50ms too slowly. 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. Then I had to program the ramping to take advantage of the ramp feature on the radio. This requires an internal timer. Anyway, I got it working so now I can move ahead. I must have recompiled, tested and traced my code using Wireshark (thanks again for the that advice) 100 times. 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. Now both spin like crazy.
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 hassles around a commercial product plus fighting with Icom as I reverse engineered their device would take the fun out. 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. But this is looking pretty cool. A slanted 3x5 LCD touch screen with an encoder and knob. There's enough horsepower in this board to also embed a CW reader, decoder for digital modes, etc. Way beyond my scope, I just want a couple more encoder dials (to hang my overweight knob on :-DD)
So now onto the LCD design. Big bug there as I can't get the USB and LCD code running at the same time, I mean WTF??. I am hoping it is just related to stack and heap sizes and not some crazy interrupt problem. Could also be the clock or just be the board I am using as many of the signal lines are dual function. The LCQ goes white when I initialize the USB device. But I have a ton of experience in LCD and TFT screens so this should work out after about 50 compiles or so.
Jerry
-
here's the STM32F469 development board I am thinking of using. It presents equivalent to an early iphone, has the same look and feel with 680x480 resolution. Only problem with the board is the one I have has developed a crack in the cable or maybe it is just loose. The screen is sort of flickering that goes away when I press on the right side where the cable is captured under the display. The display itself is no more than 1/32nd thick with a backlight about 3/32nds. The display was rubber-glued down and I guess it dried out over the year or so since I bought it.
The board itself has all the features we need including 5 leds, SDCard, audio, mics, adc, dac, etc, etc. Don't think I'll be using much of that, though. The encoder will be mounted to the right with three buttons under it. I'll use the display for the 10 buttons and wire that into the accessory jack. 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. That is much cleaner, I'll admit, but haven't figured it out. I am getting pretty good with all this USB stuff though.
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. Don't have to mess with DFU, etc.
Here's the board with an early keypad overlay from another project. I am using this one for testing and will hope to design some cooler looking buttons consistent with the IC-7610 display.
Overall, fun project now that I have it all working.
Jerry
by the way, the second USB is for the integrated debugging. The white cable goes to either a PC running RS-BA1 software or the supported Icom radio.
-
Now I'm rethinking this board as the flat cable that wraps around underneath is twitchy. I've had the board around 2yrs and I guess the flat cable has a crack. So I ordered another and will try to get ST to replace this one. Wish me luck. I have about every flavor of their STM32F4 and F7 board and this form factor seems to fit my plans.
The only encoder I have around here is a good-quality Grayhill with a detent. It goes for around $25, not the best but it works for testing. I coded an interrupt driven routine to process the encoder. Works so quickly that you can see the detents. 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. It wasn't easy but neither was all the USB code. I looked all over and couldn't find encoder code with step and direction for the HAL library instead of the standard peripherals.
The touch screen is working fine and I'm going to add a keyboard enumeration to this device so I don't have to connect to the accessory port. I should have that working by the time the new board gets here. Then I'll mount the parts on a frame. I have a heavy duty encoder with bearings on its way from eBay. I was thinking of just ordering a US Digital or Bourns encoder but thought I would try these optical encoders off eBay for this and other projects. They cost $18 and look well made.
So this project will end up costing about $100 but could have been zero if I was happy with the encoder and my STM32F469I board didn't decide to break a cable I can't even see. It looks like that flat cable has about 50 wires in it too. When I torque the board a little, it starts jumping all over the place so it must have something to do with refresh, no idea. I remember when that board came out people were wondering on the ST forum if the screen would last.
Anyway, this has been fun, very satisfying project. Just enough difficulty to keep my interest.
Jerry
-
I have everything working now and I am going back and cleaning up the code. Since the board has a mini SD card, I added an INI file that allows you to program the functions behind each of the 3 sets(or more) of buttons. Instead of emulating a keyboard on USB I now have a cable that plugs into the remote jack on my 7610 so I can send pre-programmed CI-V commands. The large center soft button in the upper middle is where you would press for transmit. I also put the operating frequency there now and mode. Since the buttons are now CI-V programmed you can send up to 72 characters of CW behind any button or better yet, send any CI-V function. This leaves the scope up on the screen while having all the CW functions handy. This along with the encoder was my original objective for the device.
The photo doesn't do it justice at all. I also still have the screen saver on.
The other picture is the Grayhill encoder I'm using. Only issue with it is the freedom of movement is really high so the knob has to be balanced or maybe a friction drag with a lock as it will settle if the knob is out of balance.
I have an acceleration ramp that along with the loose encoder and high pules per rotation, allows me to give it a spin and go across the entire band in 1hz tuning mode or zero in on a signal. This makes it many times more pleasant to use than the RC-28 which I also have. I'm going to post a video of the operations.
I started designing a box with my CAD system. I'm going to cut the prototype out of billet aluminum. It's about 7" wide and 2.65" deep, slanting back to front with the back about 1.75".
The board also has an ADC and DAC and I was thinking about adding some DSP tone functions for SSB two-tone testing but that will be down the road. I still haven't decided where the project is going but I've had a number of inquiries.
More to come.
Jerry
-
Any more news on this? I would love to build one... much nicer and more functional than the rc-28....
-
i've been traveling and not able to finish the case. I'm also not wild about the case I've designed thinking more like the ICOM detachable front panel displays now vs a simple slanted box. I have all the code running and have been tweaking the acceleration but otherwise I'm happy with the performance. I find it much nicer to use than the RC-28 as I can give it a flick and scan 50k in the 1hz tuning mode. I have the microSD card working to load CW programs for the buttons. I tried writing some PC VB code to talk to OEM logging and control programs like Rumlog and others like it works with RS-BA1 but decided to set this aside. Everything I do to it though, has to be created as there is a severe lack of available code for the STM32F4 platform using HAL. I also wrote about 10 pages of doc, mostly specs and background, but I haven't decided what to do with it yet. I find it to be really cool and handy, especially with the CI-V macros behind the buttons. It makes the 7610 more SDR without having to have a PC attached...
I have the week off between Christmas and New Years so I'll make a lot of progress then.
Jerry
-
Make any progress? Any chance you'd publish what you've got? I'm sure there a few people that would love to run with it...
-
I know this is an old topic but it was never resolved - so, if anyone is intrested I have released an arduino emulation of the RC-28 remote controller which can be used to control the RS-BA1 software.
While it is fully working I still class it as "work in progress". The code and instructions are available at https://github.com/gi1mic/rc28_emulator.
The code only works on an Arduino Pro Mini "Leanardo / 32u4" based Arduinos and requires some knowledge of working with the Arduino IDE in order to use it.
The RC-28 is the ICOM USB jog wheel for use with the RS-BA1 remote control software. The build cost, excluding case is around $40 including optical encoder, switches, LED's and tuning knob.
Gareth
-
Nicely done! de VE7FM
-
There is a Linux library to use Hercules DJ CD mixers (a popular brand) as SDR controllers
You're not alone in wanting to clone the RC-28. I've always figured it was nothing more then a mouse with a unique VID and PID. I was surprised it needed a firmware update to work properly with the IC-7610. The Griffin Powermate seems like a cheap alternative if it could be made to work.
-
Gareth-
I've been tinkering for a while on something similar - have you ever considered a branch of this project that would communicate over CI-V?
this would (as long as the CI-V address of the radio could be modified easily) make the project easily adaptable for any Icom radio
The only gotchya is that it would tie up the CI-V port, which isn't a killer for some of the newer radios (7300, 7610), but for older radios (737, 735, 706) might require addition of a CI-V bus controller to avoid collisions.
Now that I'm putting my station back together, I'm hoping to get back to this project in the near future.... unless Win4Icom adds support for some of the fancier shuttlepro type devices on the market...
-
Has anyone tried this with a 7610?
Anything further from cncjerry?
-
I have the opposite desire. I bought an RC-28 for my IC-705 only to discover that RS-BA1 does not expose all functionality (no WFM iirc.) So now I would like to repurpose my RC-28 for use with Linux radio management or other software. I haven't started this project yet but I'm posting here in case anyone else has a similar interest. This would be a software-only effort, I don't want to modify my fancy and overpriced device. I guess a driver or something although I don't know how things are abstracted in Linux.