Hi!
Today I've added rtl-sdr and osmo-fl2k to the automatic nightly package
builds at https://build.opensuse.org/project/monitor/network:osmocom:nightly
I also wanted to add them to the "latest" feeds (which build that latest
tagged version, as opposed to a nightly snapshot). However, for this to
work we need tagged versions that include the "debian" sub-directory
in the respective projects.
I hence temporarily disabled the "latest" builds until that happens,
see
https://build.opensuse.org/project/monitor/network:osmocom:nightly
Please let me know once new versions are tagged and
the above patch can be reverted. Thanks!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
There has been a considerable discussion in the past couple of days about a
device called the Tzumi MagicTV. This is an Atheros-chipset OpenWRT device
connected to an RTL2832P, which seems to be used as a bridge/DAC for a
MaxLinear MxL608 tuner and a Panasonic ATSC demodulator.
The device is sold at Wal-Mart stores for $13, and is intended to allow the
user to view OTA broadcasts using a WiFi connection to the device, which
functions as an access point by default. There also seems to be an Eardatek
Tevemo device which is similar.
>From tear-down inspection as well as poking around the file system, some
uses have concluded that the device could be used as a software defined
radio with some software modifications (for example replacing the default
ATSC server software with rtl_tcp). However, librtlsdr does not currently
support the MxL608 tuner, and right now rtl_tcp (when placed on the openWRT
device) defaults to direct sampling mode.
There is a general sense in these discussion groups that MaxLinear's source
code could be ported to work with librtlsdr, but someone would have to make
that happen.
I am sending this message to the group, to reach out with a humble
request/suggest/beg that someone(s) please help us out by doing the
following:
1. Sanity-check the claims being made; if what is being discussed is not
workable, it would be of benefit for us to be told so.
2. Start work on forking librtlsdr and porting the MxL608 driver over (if
possible/practical);
3. Coordinate with the broader community to beta-test and refine // help
spread the knowledge so that the community can maintain/improve the fork
and perhaps submit a pull-request in the future.
Please let me know if I can help you help us by procuring/shipping a couple
of hardware units for development purposes.
I understand that asking people to do volunteer work can be
presumptuous/annoying. All I can say in my defense is that there are
already at least a few dozen people who would be really happy and
appreciative if this came to fruition, and "one does not get what one does
not ask for."
Moreover, adding MxL608 support to librtlsdr might help broaden the hobby
to include a whole bunch of other devices; MaxLinear tuners seem to be used
a lot with set-top gear.
Thank you very much,
James "Gwen" Dallas, AD5NL
Reddit user: texasyojimbo
Phone: 1-713-254-4175
P.S. here are the existing discussion threads for reference:
1. RTL-SDR.com blog:
https://www.rtl-sdr.com/tzumi-magictv-wifi-tv-tuner-device-contains-an-rtl-…
2. Reddit RTLSDR group:
https://www.reddit.com/r/RTLSDR/comments/8mlbps/tzumi_magictv_is_an_openwrt…
P.P.S here is a link to the existing MxL608 driver source code:
https://github.com/avlogic/AVL6862/tree/master/2.10.7/tuner/MxL608
and data sheet: https://datasheet.lcsc.com/szlcsc/MXL608-AG-T_C141783.pdf
Hi,
I am packaging some of your software for Arch Linux. For that, I need
to fetch the source tree I want to build. The problem is that there's
no need to fetch the whole git repository to build a specific tag. As a
solution, I propose that compressed files from every tag would be
available, like GitHub releases.
Please let me know if this is something you would consider doing.
Thanks,
Filipe Laíns (FFY00)
https://github.com/FFY00
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
Sent via Migadu.com, world's easiest email hosting
I am having this problem with all of my dongles (from multiple sources) and was wondering if it could be some sort of problem with it not getting closed properly,
In all cases the chip that gets hot is the actual SDR not the tuner. But I don’t understand why it is heating up when the dongle is not in use and is just plugged in.
Or is this just some weird problem with the dongles.
Sincerely,
William
Hello,
would like to know, what is the average time that an RTL-SDR (R820T2) can
run nonstop without affecting its internals
The use case, is to sniff GSM packets
noting that sniffing will take several intervals during the day, and the
experiment should only run for 1 day , thus what could be the appropriate
interval
thanks
Is there any reason for this to be turned on during normal operation of the
RTL-SDR?
Turning it off seems to reduce current usage by 10 to 20 mA. To turn it off
set reg 0x05 bit 7 to 1. Seems to turned be on by default. Haven't seen any
effects from turning it off.
Hi gr-osmosdr maintainer,
can I respectfully ask if the several patches to the gr-osmosdr library,
sent in the past months on this list, will have a chance to be considered
in the near future?
Many thanks in advance
*am*
--
Andrea Montefusco IW0HDV
------------------------------------------
As my old boss, an Apollo veteran, would often remind us “It’s good to be
smart, but it’s better to be lucky.”
Wayne Hale, Space Shuttle Flight Director
This code stayed unchanged for many years, but for some reason
rtl_adsb started hanging upon exit:
*b66116a5164b69281eacc42ae950;
^CSignal caught, exiting!
<------ hangs here forever
Examining it with gdb reveals that the demod thread waits
peacefully on the condition variable, which we're trying to
destroy. Either the signals killed all threads before, or
condition variables were possible to destroy while other
threads still waited on them.
The easiest fix appears to be just cancel the demod thread
and wait for it to exit before proceeding for the door.
---
src/rtl_adsb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 07fdd2a..9087de4 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -492,6 +492,8 @@ int main(int argc, char **argv)
else {
fprintf(stderr, "\nLibrary error %d, exiting...\n", r);}
rtlsdr_cancel_async(dev);
+ pthread_cancel(demod_thread);
+ pthread_join(demod_thread, NULL);
pthread_cond_destroy(&ready);
pthread_mutex_destroy(&ready_m);
$ fl2k_file
fl2k_file, a sample player for FL2K VGA dongles
Usage:
[-d device_index (default: 0)]
[-r repeat file (default: 1)]
[-s samplerate (default: 100 MS/s)]
filename (use '-' to read from stdin)
$ fl2k_file -s 8192000 -
Failed to open -
I'm perfectly willing to pitch in and fix this. How do you prefer to
receive contributions?
I received following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and installed but despite this still unable to compile osmo-trx, any one can help to resolve the issue!
configure: error: Package requirements (libosmocore >= 0.11.0) were not met:
Requested ‘libosmocore >= 0.11.0’ but version of Osmocom Core Library is UNKNOWN
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.”
I have already build following components on Rasbian from source successfully
LimeSuite SoapySDR SoapyUHD libosmocore-0.11.0/ libosmocore-0.96.0
Regards
Babar
