Menu
▾
▴
Re: Controlling and reading a usb radio
|
From: Deron <de...@pa...> - 2012-05-13 04:30:12
|
On 5/8/12 3:55 AM, Hans de Goede wrote:
> Hi,
>
> On 05/07/2012 05:10 PM, Deron wrote:
>> Hello,
>>
>> I hope this is an appropriate things to post here. I have an AlertFM usb
>> radio that is "windows only" that I want to use on my Ubuntu server. The
>> plan is to set it up to listen for EAS warnings on our local radio
>> station. (We live a long way from civilization and don't always have the
>> TV on). If I can get the audio stream, I can do the rest easy enough
>> (I've got that part written and tested using recordings of EAS audio
>> messages).
>>
>> Anyway, I have a windows computer and captured some channel changing
>> data using their software, and digging around I found this software
>> which actually recommends hidapi for HID devices. No problem, I have
>> that installed along with libusb and I think I even have it changing
>> channels (one report sets the channel, and another reads back the
>> current channel. Still an input report I can't seem to grab which gives
>> signal strength data etc, but I could live without that.)
>>
>> What I don't have now is the audio stream. I'm not very familiar with
>> USB, so this is a really basic question, but what do I do to read that
>> data? I'm guessing that hidapi won't be able to read that data, and
>> somehow need to mix in calls with libusb? I've not had much luck finding
>> sample applications for hidapi, and if someone could just nudge me in
>> the correct direction I would appreciate it or even basic info on USB
>> that would fluff out my knowledge without have to read an encyclopedia
>> on USB.
>
> I see that you've already gotten several useful replies further in the
> thread. So it looks like getting the audio from the device is a solved
> problem, which only leaves the tuning. Tuning normally is handled
> by v4l2 kernel driver.
I'm not so sure. Using the ALSA command:
arecord -l
shows:
card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: ALC889 Analog [ALC889 Analog]
Subdevices: 2/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
card 1: Radio [ALERT FM Radio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
But
arecord -D "plughw:CARD=Radio" -f cd >audio.raw
Give me static. Ok, but a simple little program using hidapi appears to
set the freq, but all I get are "clicks" in the arecord output that
conincide with the attempts to change the frequency. I even tried
looping through all frequencies every ten seconds but no go.
>
> Chances are that your device is using the si470x chipset, as that uses
> a usb-audio class interface for the audio and a hid interface for
> tuning...
I took it apart awhile ago, and it is using an si part, but I don't
recall that being the number. I'll have to find my notes...
Ok, best as I can see here are the number from the si chip is:
silabs
f321
ecnab3
o741+
> To test this you would need to do the following (as root):
>
> 1) plug in the device
> 2) do dmesg, you should see something like this in there:
> usb 2-1.5: New USB device found, idVendor=12cf, idProduct=7111
Not exactly what I get. I get:
[ 6.940474] generic-usb 0003:12CF:7111.0001: hiddev0,hidraw0: USB HID
v1.11 Device [Axentia Technologies AB ALERT FM Radio] on
usb-0000:00:1a.1-1/input2
[ 6.940494] usbcore: registered new interface driver usbhid
[ 6.940496] usbhid: USB HID core driver
> Note the 2-1.5
> 3) "cd /sys/bus/usb/drivers/usbhid"
> 4) "ls"
> You should see a symlink in there starting with the same prefix as in the
> dmesg, followed by :1.2, ie: "2-1.5:1.2",
Ok, I see:
9-4.1:1.0
9-4.4:1.0
4-1:1.2 <- second time around I see this!
Which I can't correlate to any of the dmesg output. They link to:
../../../../devices/pci0000:00/0000:00:02.0/0000:0e:00.0/usb9/9-4/9-4.1/9-4.1:1.0
../../../../devices/pci0000:00/0000:00:02.0/0000:0e:00.0/usb9/9-4/9-4.4/9-4.4:1.0
And appear to be the mouse and keyboard.
> then do:
> 5) "echo '2-1.5:1.2' > unbind"
> Replacing 2-1.5:1.2 with the address string for your device
Just for kicks, I went ahead and unbound the two devices.
> 6) "modprobe radio-usb-si470x"
> 7) "cd /sys/bus/usb/drivers/radio-si470x"
> 8) "echo '0x12cf 0x7111' > new_id"
> 9) ls, now the 2-1.5:1.2 like string should be there, if not
> see "dmesg" for errors :|
Well, I now see 4-1:1.2 ->
../../../../devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.2
> 10) "ls /dev/radio*"
> If there is a radio device there things seem to be working!
And I now see /dev/radio0
>
> Now start a program recording / looping back sound from
> the alsa device for the usb-stick, and then start a radio
> tuning program, for example the very simple "radio" app
> from xawtv.
"radio" appears to get a little further along. It actual seems to enable
the radio in so much as when it is running, I get what seems like real
radio static as to the just near silence I get otherwise. But I don't
get any change in the output no matter the frequency tuned.
>
> ###
>
> If the above does not work, it looks like you do need to write
> some software to drive the device yourself after all. IMHO the end
> result of this project would be to write a v4l2 kernel driver.
No problem. I'm happy to do what I can.
>
> For starters we can write a little libusb program, but once we've
> put in that effort why not go all the way and make it usable as a
> normal/standard radio device under Linux?
>
> The first step would be to catch some USB-traces of windows setting
> the frequency, or iow windows doing some tuning to a radio station.
I have some of that, and maybe this will tell you at a glance if it
should be compatible. Here is the output from a Windows program. It was
something like USBalizer or some such. I cut out the repeating parts
(the "input report"). Frequency was 107.7 when I started the capture,
and then 107.7 -> 107.9 -> 87.5 -> 87.7.
Input Report id:18 len:13 12 02 05 FC 65 41 A5 3E 10 3E 9F
3C 08 repeating
Set Report (Feature id:4 len:3) 04 80 66
setting freq to 107.9
Get Report (Feature id:11 len:64) 0B 02 05
x9
Get Report (Feature id:11 len:64) 0B 02 01
x17
Input Report id:18 len:13 12 02 05 FC 65 41 A5 3E 10 3E 9F 3C
08 x1
(3rd element corrisponds to
RSSI in the Windows AlertFM interface) (5th element appears to
corrispond to BER in the Windows AlertFM interface)
Get Report (Feature id:11 len:64) 0B 02 01
x22
Get Report (Feature id:11 len:64) 0B 42 06
x1
Set Report (Feature id:4 len:3) 04 00 66
Get Report (Feature id:12 len:64) 0C FC 66
x1
Input Report id:18 len:13 12 02 04 FC 66 41 A5 3E 10 3E 9F 3C
08 repeating
Input Report id:18 len:13 12 02 05 FC 66 41 A5 3E 10 3E 9F 3C
08 repeating
Set Report (Feature id:4 len:3) 04 80 00
setting freq to 87.5 (it appears that the value they use is
(freq - 87.5) * 5 )
Get Report (Feature id:11 len:64) 0B 02 04
x
Input Report id:18 len:13 12 02 04 FC 66 41 A5 3E 10 3E 9F 3C 08
Get Report (Feature id:11 len:64) 0B 02 14
Input Report id:18 len:13 12 02 14 FC 00 41 A5 3E 10 3E 9F 3C 08
Get Report (Feature id:11 len:64) 0B 02 14
Set Report (Feature id:4 len:3) 04 00 00
Get Report (Feature id:12 len:64) 0C FC 00
Input Report id:18 len:13 12 02 15 FC 00 41 A5 3E 10 3E 9F 3C 08
Input Report id:18 len:13 12 02 13 FC 00 41 A5 3E 10 3E 9F 3C 08
Feature Report
02 0a 50
waiting...
Data read:
12 14 18 f8 00 42 3f d6 0c c7 c2 85 d9
Set Report (Feature id:4 len:3) 04 80 01
setting freq to 87.7
Get Report (Feature id:11 len:64) 0B 02 14
Get Report (Feature id:11 len:64) 0B 02 11
Input Report id:18 len:13 12 02 14 FC 00 41 A5 3E 10 3E 9F 3C 08
Get Report (Feature id:11 len:64) 0B 02 11
Set Report (Feature id:4 len:3) 04 00 01
Get Report (Feature id:12 len:64) 0C FC 01
Input Report id:18 len:13 12 02 11 FC 01 41 A5 3E 10 3E 9F 3C 08
Input Report id:18 len:13 12 12 10 FC 01 41 A5 3E 10 3E 9F 3C 08
I did not capture from the beginning to the end of startup etc. I can go
back and do that if helpful and post uncut results to a page somewhere
on one of my web sites.
Thanks for your great email!
Deron
>
> The way to do that now a days is to start windows inside a vm under Linux
> and then redirect the usb device to the windows vm.
>
> When you've the device working inside a windows vm, then:
> -figure out on which usb bus the device sits (lsusb will tell you this)
> -shutdown the windows vm
> -unplug the device
> -start wireshark as root and ignore the security warning, it is not
> really
> relevant when using wireshark to monitor usb devices
> -tell wireshark to record usb transfers on the bus the device was on
> -re-plug in the device, this needs to happen after starting wireshark,
> so that wireshark sees the usb device descriptors come past and can
> thus automatically load the right protocol dissectors
> -write down where in the log wireshark now is, as everything up till this
> point was send by the standard linux hid and audio drivers
> -start the vm and redirect the device to it
> -write down where in the log wireshark now is, as everything up till this
> was windows initialization which is likely not interesting
> -start the windows radio app, look in the wireshrak log for any HID
> messages,
> these are likely doing the tuning
> -tune to a certain frequency if possible (ie no auto tuning, but pick
> a fixed freq.),
> write down where in the log you are, and what frequency you tuned to
> -tune to a another frequency if possible (ie no auto tuning, but pick
> a fixed freq.)
> write down where in the log you are, and what frequency you tuned to
> -stop the windows radio app
> -stop wireshark capturing usb packets
> -save the capture in wireshark!
>
> And then you can go and try to figure things out from the capture.
> Note besides
> a libusb developer I'm also a v4l2 developer and have reverse
> engineered quite
> a few usb devices. This sounds like a fun little project and I would
> like to help,
> which requires me getting my hands on such a device...
>
> Regards,
>
> Hans
>
|
