It looks like I'm not the first person to have notices this, because after
I submitted a PR to the github project, I noticed another pull request
dating from May that has yet to make it into master.
Essentially what it boils down to is that char on arm systems, in my case
the raspberry pi, are treated as unsigned characters. So right now we have
a fix for the hackrf firmware update that only works on x86 systems. A
simple change to the source and sink typecasting from char to explicit
int8_t on the lookup table on the source.cc should fix this issue for all
platforms. In addition, I believe a typecast in the convert function for
the sink.cc would do it as well but I have not tested it and I don't
believe my current PR reflects that either.
Hi all,
I've created a simple little change for rtl_fm which outputs values of 0
(instead of nothing) when the output is squelched. Use the command
option "-E nullsquelch" to enable.
This is useful when live streaming output to icecast or similar which
requires a constant stream of data (such as
http://rtl-sdr.com/forum/viewtopic.php?f=7&t=141 or
http://www.windytan.com/2013/07/squelch-it-out.html).
Hopefully someone can merge this into the git repo, otherwise just patch
and build yourself.
Cheers,
Wilson
--
*Wilson Waters* | Software Engineer
*Alintech*
e: wilson.waters(a)alintech.com.au
w: www.alintech.com.au
Hi,Can someone inform us if the VTY configuration commands to change parameters e.g. cell id, location area code, MS power etc. that are run on OpenBSC VTY telnet interface take effect on next restart of the OpenBSC session or during the same session? If former is the case, is there any way to dynamically change Cell ID, LAC, MS TX power etc i.e. without restarting the OpenBSC session?
Regards,
Amber & Sarosh
Hi all,
I've created a simple little change for rtl_fm which outputs values of 0
(instead of nothing) when the output is squelched. Use the -E
nullsquelch option to enable.
This is useful when live streaming output to icecast or similar which
requires a constant stream of data (such as
http://rtl-sdr.com/forum/viewtopic.php?f=7&t=141).
Cheers,
Wilson.
This patch implements zero-copy overhead for buffers used for sample
transfer. This improves a bit performance for applications where low
overhead is required and can save a bit of memory.
Two changes are made:
* add return value for callback function
* add function for buffer release when it is free for reuse
This change breaks ABI (callback returns int instead of void), but I
cannot find way not to do so. Proper change of library version in
CMaleList.txt would be required.
Please comment on it and let my now if it is interesting enough to be
merged upstream.
JP
Checking if variable is not NULL before calling free() is not effective,
because free() already does this.
- waste instruction and/or compiler time
- more lines of code than necessary
This patch removes those checks.
Hey list,
I recently put together SoapyRemote, which is a plugin and server app
for SoapySDR that lets any supported hardware operate as a network
device over a local link: https://github.com/pothosware/SoapyRemote/wiki
GrOsmoSDR users should be able to use the Osmo source and sink blocks to
work transparently with a remote device. Just make sure that GrOsmoSDR
was configured with the support for SoapySDR. I have documented how the
device args should be set to use a remote device:
https://github.com/pothosware/SoapyRemote/wiki#grosmosdr-remote-devices
Extra note: Everything works better with large socket buffers. On linux,
users will want to run the sysctl commands here:
https://github.com/pothosware/SoapyRemote/wiki#remote-window
I had a lot of fun making SoapyRemote, and we have already seen that
working with embedded devices has been a big use case. I hope that
GrOsmoSDR users will find utility with SoapyRemote as well.
Thanks, and happy hacking!
-josh
Hello Dimitri,
I've put together two simple gr-osmosdr blocks for the Red Pitaya SDR
transceiver. They are based on the file block with some pieces borrowed
from the rtl_tcp block. Would it be possible to add these blocks to the
gr-osmosdr code repository?
The patch is in the attachment.
Some information about the Red Pitaya SDR transceiver can be found at:
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver
Best regards,
Pavel
Hello,
I'm working on the gr-osmosdr blocks for the Red Pitaya SDR transceiver.
They are based on the file block with some pieces borrowed from the
rtl_tcp block.
The new blocks are already working and the code can be found at:
https://github.com/pavel-demin/gr-osmosdr/tree/master/lib/red_pitaya
My notes about the Red Pitaya SDR transceiver can be found at:
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver
I have two questions that I can't find an answer to:
- What would be the best way to implement the push-to-talk (PTT)
command? I don't see any method reserved for this kind of functionality
in gr-osmosdr/lib/sink_impl.h. I can think of putting it to set_if_gain
or set_bb_gain but I'm not sure if it's a good idea.
- Once the PTT problem solved, what would be the best way to submit a
patch with my modifications?
Best regards,
Pavel