Dear gr-osmocom developers,
I have a project that uses Jetson Xavier NX and BladeRF 2.0 to transmit and
receive radar signals. I decided to use GNU Radio and gr-osmocom to do that
task. Unfortunately, I encountered an error that, I think, GNU Radio failed
to read all the parameters. This is the first time that I face this kind of
error. I have been using GNU Radio for a while in a PC or Raspberry Pi but
never see an error like this.
Do you have any idea where is this error coming from and how to deal with
it?
Your suggestions are highly appreciated. Thank you.
Best regards,
Edwar
[image: Screenshot from 2025-02-14 10-52-25.png]
in osmocom sink and source.
Hi,
I just stumbled across the problem that osmocom_fft's default recording
filename does not contain the timezone.
I think it would be a good idea to change that, and I hope you agree :)
The change I propose is relatively simple:
diff --git a/apps/osmocom_fft b/apps/osmocom_fft
index c48ac7ee15..05a6de842c 100755
--- a/apps/osmocom_fft
+++ b/apps/osmocom_fft
@@ -326,7 +326,7 @@ class app_top_block(gr.top_block, Qt.QMainWindow):
s = self._fre.text()
s = s.replace('%S', '%e' % self.src.get_sample_rate())
s = s.replace('%F', '%e' % self.src.get_center_freq())
- s = s.replace('%T', datetime.datetime.now().strftime('%Y%m%d%H%M%S'))
+ s = s.replace('%T', datetime.datetime.now().astimezone().strftime('%Y%m%d%H%M%S%z'))
return s
def _set_status_msg(self, msg, timeout=0):
CU,
Sec
--
"This 'telephone' has too many shortcomings to be seriously considered
as a means of communication. The device is inherently of no value to
us." -Western Union internal memo, 1876
Hi all,
I've attached a patch that fixes a build error for osmo-fl2k under
mingw. It seems that __argc and __argv are #defined by mingw as
function calls. The patch simply removes the underscores in the
argument names.
Some of the errors:
osmo-fl2k/src/fl2k_fm.c: In function 'main':
osmo-fl2k/src/fl2k_fm.c:455:35: error: passing argument 1 of
'getopt_long' makes pointer from integer without a cast [-Wint-
conversion]
455 | opt = getopt_long(argc, argv, "d:c:f:i:s:",
long_options, &option_index);
| ^~~~
| |
| int
In file included from /usr/x86_64-w64-mingw32/sys-
root/mingw/include/_mingw.h:10,
from /usr/x86_64-w64-mingw32/sys-
root/mingw/include/corecrt.h:10,
from /usr/x86_64-w64-mingw32/sys-
root/mingw/include/corecrt_stdio_config.h:10,
from /usr/x86_64-w64-mingw32/sys-
root/mingw/include/stdio.h:9,
from osmo-fl2k/src/fl2k_fm.c:26:
osmo-fl2k/src/getopt/getopt.h:151:29: note: expected 'int *' but
argument is of type 'int'
151 | extern int getopt_long (int __argc, char *const *__argv, const
char *__shortopts,
| ^
osmo-fl2k/src/fl2k_fm.c:455:41: error: passing argument 2 of
'getopt_long' from incompatible pointer type [-Wincompatible-pointer-
types]
455 | opt = getopt_long(argc, argv, "d:c:f:i:s:",
long_options, &option_index);
| ^~~~
| |
| char **
In file included from osmo-fl2k/src/fl2k_fm.c:27:
osmo-fl2k/src/getopt/getopt.h:151:50: note: expected 'char * const**
(*)()' but argument is of type 'char **'
151 | extern int getopt_long (int __argc, char *const *__argv, const
char *__shortopts,
| ^
Thanks,
-Phil
Hi, I just saw that the major version number was recently bumped on the
osmocom rtl-sdr.
Unfortunately this seems to be causing upgrade problems because if a user
updates the drivers to the new major version number (eg to get Blog V4
support), the soname is now different, and this means that all previously
installed software that uses librtlsdr will need to be recompiled from
scratch, and software from the package manager will simply be broken.
I'm not sure if the recent changes warrant a major version change and the
problems that come with it?
Regards,
Carl
Empower your journey in customer relationship management (CRM) with our comprehensive support services. Our team specializes in providing expert guidance and assistance tailored to your CRM assignment needs. From analyzing customer data to implementing effective strategies, our CRM Assignment Help ensures you're equipped with the knowledge and skills to excel. Trust us to be your partner in success as you navigate the complexities. Let our expertise be at your fingertips, guiding you toward academic achievement and more visit our website Now.
https://reportwritinghelp.com/assignment/consumer-behavior-assignment-help
Hi all,
I was approached by the person currently holding the [unused] airprobe.org
domain name. I guess it was at some point registered and intended to be used
for the project (back in the pre-osmocom days). As far as I know it was never
actually used for that.
So the question is now if anyone wants to get that domain transferred in
order to do something useful with it, or whether the current registrant
should simply let it expire?
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi All
I bought a cheap DVB-T stick that was supposed to be a RTL2832U with a
FC0012 tuner with RTL-SDR support. As might have been expected given the
price, it doesn't work. The various rtl_ tools all report "No supported
tuner found", eg rtl_eeprom gives:
> Found 1 device(s):
> 0: Generic RTL2832U OEM
>
> Using device 0: Generic RTL2832U OEM
> No supported tuner found
> Enabled direct sampling mode, input 1
>
> Current configuration:
> __________________________________________
> Vendor ID: 0x0bda
> Product ID: 0x2838
> Manufacturer: Realtek
> Product: RTL2838UHIDIR
> Serial number: 00000001
> Serial number enabled: yes
> IR endpoint enabled: yes
> Remote wakeup enabled: no
> __________________________________________
The vendor did give me a full refund suspiciously quickly, so clearly the
lack of advertised RTL-SDR compatibility is well known to them!
I then took the cover off, and it does have a chip that's labelled
RTL2832U, plus another similar sized one I can't read the label of.
After a bit of searching, I found this old post with a patch to list all
the I2C devices:
https://www.mail-archive.com/osmocom-sdr@lists.osmocom.org/msg00454.html
That reports:
> I2C devices found:
> 20 a0 a2
So there is something working there, but I'm not sure if it's enough...
Is there any hope for this stick? And if so, what would my next steps be?
Thanks
Nick
Hello various Osmocom mailing lists,
the official Osmocom binary packages will not be built anymore for the
following distributions starting at 2024-02:
* Raspberry Pi OS 64-bit (use Debian_12 etc. instead)
* Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available)
* openSUSE 15.4 (openSUSE Tumbleweed feed is available)
* Debian Testing (Debian Unstable and 12-10 feeds are available)
For Raspberry Pi OS 64-bit users, make sure to adjust your
/etc/apt/sources.list.d as described here to switch to a Debian
aarch64 feed:
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
See the new linux distributions article for information on how long we
plan to keep building packages for each distribution:
https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio…
Let me know if you have questions.
Best regards,
Oliver
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte