Action Item #557
closed
Port XimbaRadio
Added by Hammel about 8 years ago. Updated over 4 years ago.
100%
Description
Either run it with Perl (as it is now) or port the library to C and call from XimbaRadio app.
Updated by Hammel about 8 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Some links of interest:
- Protocol specification - discussion on protocol
- mmxmpcr - C++ program but is missing some pieces
Updated by Hammel about 8 years ago
- % Done changed from 10 to 70
This is done though it's not been tested as a package on hardware. But the app works fine on my laptop. I like it better than the old XimbaRadio. The new UI is simpler and matches the UI of VideoFE. Sadly the audio is output over an external audio port, not via the USB. I should be able to hook a Bluetooth transmitter to it, however.
Next up:- Verify packaging
- Make sure the required app files are available
- Test on hardware
- can the RPi Model 2 drive this box? The external hub should be able to.
- Does the ttyUSB port come up as expected under PiBox?
Updated by Hammel about 8 years ago
- % Done changed from 70 to 80
Packaging cleaned up and now builds correctly.
Updated by Hammel about 8 years ago
- The UI needs to set the labels right justified but not expanded/filled.
- The UI needs the text fields for station, etc. expanded and filled.
- The UI needs a field to show "device not available" when initialization doesn't work. A button (say "R" for restart/reload) should cause the device init and channelMgr thread to be started again, after the device is setup.
- The ttyUSB port is missing.
Updated by Hammel almost 8 years ago
Ugh. More power supply issues. The radio works fine on my laptop but doesn't work on my desktop with an external, powered USB hub. It also doesn't work on the Raspberry Pi either directly connected or connected to the external USB hub. I need to measure USB power to see if this might really be the problem. I can try this: https://www.amazon.com/Centech-USB-Power-Meter/dp/B00DAR4ITE
Here is yet more research on power to USB ports:- https://jarretdyrbye.wordpress.com/2013/12/31/a-diy-power-supply-for-hi-fi-usb-audio-with-your-raspberry-pi/
- http://forum.allaboutcircuits.com/threads/stabilizing-a-usb-5v-in-reality-anywhere-from-4-5-to-5-5-power-source-to-a-true-5v-source.117217/
- http://plugable.com/2013/07/22/usb-hubs-and-chargers-what-happens-when-you-pull-too-much-power/
- http://electronics.stackexchange.com/questions/12935/stability-of-usb-5v-output
- http://www.howtogeek.com/228869/how-to-monitor-your-usb-device-power-usage-and-output/
Updated by Hammel almost 8 years ago
Stabilizing power might be possible by placing a big capacitor (100-1000uF perhaps) inline to the power line on the usb connection. Sparkfun has a tutorial on using capacitors. I should also check with Plugable's support, which has info on how they handle power to USB ports.
Updated by Hammel almost 8 years ago
- Update the UI as the channel scan is in progress.
When a rescan is done, rebuild the category listThe /dev/ttyUSB0 port needs to have "other" read perms. But why?- The current channel should be scanned often to update on the UI.
Updated by Hammel almost 8 years ago
- Project changed from PiBox to pixm
- Category deleted (
04 - Applications)
Updated by Hammel over 5 years ago
- Target version changed from 0.12.0 to 1.1.0 - Upgrades
Updated by Hammel over 4 years ago
- Priority changed from Urgent to Immediate
- Severity changed from 01 - Critical to 04 - Low
Updated by Hammel over 4 years ago
Here are the updates to be made for each tweak.
Update the UI as the channel scan is in progress.¶
- mgrProcessor should be turned into a g_timeout_add() to simplify things. It just needs to run on a periodic basis and shutdown can just kill the timer.
- If the timer goes off but the last mgrProcessor is not complete then it should skip that iteration.
- mgrProcessor should rescan the current channel in one of its passes.
- when mgrProcessor completes it needs to call populateList
- populateList must do a gtk_widget_queue_draw(GTK_WIDGET()) which is probably needed because the widget update is happening outside the event main loop.
When a rescan is done, rebuild the category list¶
This isn't necessary as every response is checked to see if a new category has been found. However, addCategory() probably needs to support more than 256 categories.
The /dev/ttyUSB0 port needs to have "other" read perms. But why?¶
pixm needs to run privileged so it needs to be added to appmgr.priv by the postinst script in the opkg.
The current channel should be scanned often to update on the UI.¶
This is a new mode to add to mgrProcessor. We need to scan the current channel once a second or so. If we're using a g_timeout then every fourth time through (or so) should be a rescan of the current channel.
Updated by Hammel over 4 years ago
- % Done changed from 80 to 90
The UI scan can't update the display on changes to the lists because the user can't select anything if that happens. So TAB is the only way to do that right now and that's they way it's going to stay.
The current channel update exposed major problems with how the device was being queried for data and when the UI would be updated. This required changes to how the device is queried, how the port would be opened/closed on a per command basis, and how the channelMgr thread would iterate through its operations. These are all fixed and the result appears to be, at least on my little (Chrome) laptop, much better performance and responsiveness.
This code is tested, committed and pushed. But there is a bunch of cleanup still to be done. So this isn't quite done yet.
Updated by Hammel over 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
Okay, code cleaned up. Retested and validated as working (quite well, actually).
Committed, tested and pushed.
Closing issue.