Hi!
today I discovered that the gr-osmosdr package in debian unstable contains
a whooping list of 96 patches. This is due to the fact that since November
2014 there hasn't been any tagged versions in the repository.
I'd like to suggest to tag releases a bit more often.
@horizon: What about jumping to 1.0.0 right away?
Regards,
Harald
--
- 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)
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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)
With just 'inline', if the compiler decides not to inline them, it isn't
required to emit them at all. For some targets with -Os that is causing
build failures.
Perhaps we might consider using '__attribute__((always_inline))' for
GCC builds, but 'static inline' is a good start.
---
src/rtl_adsb.c | 8 ++++----
src/rtl_power.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 9087de4..7aea8dd 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -183,7 +183,7 @@ int magnitute(uint8_t *buf, int len)
return len/2;
}
-inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
+static inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
/* takes 4 consecutive real samples, return 0 or 1, BADSAMPLE on error */
{
int bit, bit_p;
@@ -224,17 +224,17 @@ inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d
return BADSAMPLE;
}
-inline uint16_t min16(uint16_t a, uint16_t b)
+static inline uint16_t min16(uint16_t a, uint16_t b)
{
return a<b ? a : b;
}
-inline uint16_t max16(uint16_t a, uint16_t b)
+static inline uint16_t max16(uint16_t a, uint16_t b)
{
return a>b ? a : b;
}
-inline int preamble(uint16_t *buf, int i)
+static inline int preamble(uint16_t *buf, int i)
/* returns 0/1 for preamble at index i */
{
int i2;
diff --git a/src/rtl_power.c b/src/rtl_power.c
index 00f4d9f..625d818 100644
--- a/src/rtl_power.c
+++ b/src/rtl_power.c
@@ -250,7 +250,7 @@ void sine_table(int size)
}
}
-inline int16_t FIX_MPY(int16_t a, int16_t b)
+static inline int16_t FIX_MPY(int16_t a, int16_t b)
/* fixed point multiply and scale */
{
int c = ((int)a * (int)b) >> 14;
--
2.17.1
Hi all,
So I decided to add support for SpyServer in gr-osmosdr. It is currently
at a fork of mirrored in github: https://github.com/racerxdl/gr-osmosdr
What should be my next steps to get this to the official branch?
--
Lucas Teske
Teske Virtual System
GPG: BD29 7EF3 4CCB EB61 B790 06C3 351A 8000 DEAD CE11
GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE
GPG: BD09 9175 6DE8 37F4 08D3 B296 DE7A 51C3 87C9 27EE
Hi everyone @ gr-osmosdr,
I have created a small pull request to fix compilation with boost-1.67.
I filed it on your github mirror, but am not sure that's the way to
make a contribution.
It's available here:
https://github.com/osmocom/gr-osmosdr/pull/13
I'll also include the patch here for completeness:
diff -ura gr-osmosdr.orig/lib/CMakeLists.txt gr-osmosdr/lib/CMakeLists.txt
--- gr-osmosdr.orig/lib/CMakeLists.txt 2018-06-10 12:06:35.662484236 +0200
+++ gr-osmosdr/lib/CMakeLists.txt 2018-06-10 12:06:51.886207437 +0200
@@ -43,6 +43,8 @@
time_spec.cc
)
+list(APPEND Boost_LIBRARIES pthread)
+
GR_OSMOSDR_APPEND_LIBS(
${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES}
Cheers,
Maxime
Hi Torben,
I'm replying with the mailing-list in Cc, as this might also be
interesting for others.
As mentioned earlier, the issue is that the FL2000 has a very inflexible
I2C implementation that was only intended (I guess?) for I2C EEPROMs.
The PCF8574 you want to use is much simpler, as it expects only one data
byte after being addressed.
If you can live with only 6 of the 8 outputs on your port expander, you
might still be able to get it working.
What the FL2000 does for an I2C write is the following:
START, I2C_ADDR(W), REG_ADDR, DATA[0], STOP
START, I2C_ADDR(W), REG_ADDR+1, DATA[1], STOP
START, I2C_ADDR(W), REG_ADDR+2, DATA[2], STOP
START, I2C_ADDR(W), REG_ADDR+3, DATA[3], STOP
As you can see, REG_ADDR is the first byte of data that is being sent to
the device after the address. This is where you need to put the data
you want to set on the IO expander outputs. As the FL2000
auto-increments the register address, you need to set the lowest 2 bits
to 0, so that the increment is not carried to the higher bits. But that
also means that output 0 and 1 of your port-expander will toggle with
each write and are not controllable by you.
>From the datasheet of the PCF8574:
"If other data bytes are sent from the master, following the
acknowledge, they are ignored by this device."
That means that DATA[0-3] are completely ignored, which probably means
that the device will send a NAK for that byte.
So the transfer always will fail from the view of the FL2000, so you
must ignore the return value of fl2k_i2c_write(), which means you also
have no feedback if the slave is actually present or not.
The first thing I would suggest trying is writing a non-zero reg_addr to
all possible slave addresses and observe the output of the port
expander. If you have a logic analyzer, I suggest to use that and have a
look at the I2C bus.
If all that doesn't work, using a small MCU and dealing with the FL2000
I2C oddities there is probably the easiest solution.
Regards,
Steve
On 17.06.2018 21:11, Torben Keil wrote:
> Hi Steve,
>
> I tried my luck with i2c... but I wasn't successful.
> There's a PCF8574 (Portextender) connected directly on the I2C interface
> of fl2k.
>
> Here's my code:
>
> torben@Mworkstation: <mailto:torben@Mworkstation:>~/Amateurfunk/C++$ cat
> fl2k_i2c.cpp
> // g++ fl2k_i2c.cpp -L/home/torben/Amateurfunk/osmo-fl2k/build/src
> -I/home/torben/Amateurfunk/osmo-fl2k/include -losmo-fl2k -o fl2k-i2c_test
> #include "osmo-fl2k.h"
> #include <iostream>
> #include <bitset>
>
> int main (int argc, char *argv[] ) {
> int status;
> fl2k_dev_t *dev = NULL;
> uint8_t i2c_addr = 0b01000001; // Letztes Bit: Read / #Write
> uint8_t reg_addr = 0;
> uint8_t *data = new uint8_t[10];
> uint32_t dev_index = 0;
>
> fl2k_open(&dev, (uint32_t)dev_index);
> if (NULL == dev) {
> std::cerr << "Failed to open fl2k device " << dev_index
> << std::endl;
> return -1;
> }
>
> for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> status = fl2k_i2c_read(dev, i2c_addr, reg_addr, data);
> if( status >= 0 ) {
> std::cout << "Adress: " << i2c_addr;
> std::cout << "; I2C-Status: " << status << "; Data: ";
> for( int i=0; i<static_cast<int>(status); i++) {
> std::cout << " " << std::bitset<8>(data[i]);
> }
> std::cout << std::endl;
>
> }
>
>
> data[0]=127;
> for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> //fl2k_i2c_write(fl2k_dev_t *dev, uint8_t i2c_addr, uint8_t
> reg_addr, uint8_t *data);
> status = fl2k_i2c_write(dev, i2c_addr, 0, data);
> if( status >= 0 ) {
> std::cout << "Write Adress: " << i2c_addr;
> std::cout << "; I2C-Status: " << status << std::endl;
> } else {
> std::cout << static_cast<int>(i2c_addr) << "\t";
> }
> }
> }
>
> fl2k_close(dev);
>
> free(data);
>
> return 0;
>
> }
>
> Output of that program after a fresh reboot of the system:
> torben@Mworkstation:~/Amateurfunk/C++$ ./fl2k-i2c_test
> Kernel mass storage driver is attached, detaching driver. This may take
> more than 10 seconds!
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
> 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
> 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
> 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
> 117 118 119 120 121 122 123 124 125 126 127
>
> So there's nothing reachable via I2C.
>
> What am I doing wrong here?
>
>
> Greetings,
> Torben
>
>
>
> Am 17.06.2018 03:18, schrieb Steve Markgraf:
>> Hi Torben,
>>
>> On 16.06.2018 09:40, Torben Keil wrote:
>>> do you have a git repository for the code so that I could have a try?
>>
>> I've debugged and cleaned up the I2C code and just pushed it.
>> I2C transfers with the FL2000 seem to fail from time to time, so make
>> sure to check the return code of fl2k_i2c_read()/fl2k_i2c_write().
>>
>> Regards,
>> Steve
Hello List,
I tried to get a signal over the i2c interface but it wasn't sucsessful.
Do you have an idea how to enable the i2c interface on the fl2k chip?
Best whishes,
Torben
Hi Marcus and thanks for your reply.
>Your video is about 13 minutes longer than I'd like – can you pinpoint
>at which time in that video your transmission stops?
You can watch this video between 7:00 & 8:00 to observe the breakdowns.
>As usual, debugging on the side of the observing party might very well
>be helpful here. Figure out whether the program halts (a software
>debugger, e.g. gdb, would be the appropriate tool), the USB transfers
>stop (wireshark might be helpful here), or whether just something
>happens inside the device while the computer and software happily
>continue to work. Observing the spectrum might help.
You just gave me a good point to start debugging this issue! Actually I don’t have a RTL-SDR or anything else in hand right now to observe the spectrum but I will do the tests soon.
--------------------------------------------
Hi Steve, did a great job!
>This will happen if the host cannot supply enough data to the device,
>you need to use a lower sample rate in this case, or get rid of
>a hypervisor like VMware, as is the case in this video.
I tried fl2k_fm both in VMWare and in GNU radio live image booted from a flash drive and in both I had the problem. and why should I use a lower sample rate when my system can handle the samples well? (take a look at attachments)
I’m using VMWare Workstation Pro (Version: 14.1.2 build-8497320) on a brand new ACER laptop (Model: Aspire A715-71G-71Y3) running Windows 10 Pro 1803 (Build: 17134.112) with 16 gigabyte RAM and an Intel Core i7 7700HQ CPU. The USB host controller is Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) witch I believe it can handle up to 157 MS/s. all drivers are updated.
However, I didn’t see anything wrong with virtualization except that the maximum achievable sample rate was a little lower than the GNU radio live booted from flash drive. Except for this, I didn't encounter by anything.
>There seems to be a 'frame loss' mechanism to detect this in through an
>interrupt transfer, but I haven't implemented this yet and have no idea
>if this works with disabled synchronization.
Looking forward to the results!
And don’t mind asking me for a helping hand. I’ll do my best to help this project.
I was reading the comments below this post in rtl-sdr.com blog and I saw a user who had the same issue mentioned something that might be useful:
Of futher note (hopefully someone from osmocom will see this) the bug where the broadcast intermittently ceases in fl2k_fm under both an ubuntu virtual machine and directly ran as a windows exe seems to have something to do with cpu affinity and / or process priority – generally it starts spitting out the underflow message on stdout then the signal drops out and the process requires a restart.
Regards,
Sajjad
Hey all:
Just a heads up, the certificate on the mailing list site has expired.
It expired two days ago, 12 June 2018.
Since it's signed by Lets Encrypt, shouldn't be too hard to update,
but you might want to do that ;)
Cheers,
--
Tom Swartz
Hello. I have some problems.I want to create a GSM network for my final
diploma project for University.I'm using USRP2 and I haven't find any
specific configuration files for this type of USRP.Do you have any
configuration files for USRP2? I'm running Kali Linux (amd64). I've
attached the config files that I've used from osmocom.org and some
printscreens.Sorry for my English.I'm looking forward for your
response.Thank you!
Hi all,
as some of you know Osmo-fl2k has a bothersome software issue that sometimes just stop transmitting without any good reason. in my case when I was transmitting WBFM sometimes it may stop transmitting. I mean the RF output will be interrupted completely without any error or warnings on screen and I should re-execute the commands to transmit again and this goes on and on. sometimes it may work without any issues for like 10 min and sometimes it may fail after just a few seconds. the problem also appeared in executing <fl2k_file> when I was transmitting DVB-T.
you can watch this video to gain a better understanding: https://www.youtube.com/watch?v=G0tjzPHFFA8
I have no idea if this issue been discussed earlier in the mailing list or not, anyway I didn't find anything useful by Googling.your comments and suggestions are greatly appreciated.
Regards,Sajjad
Hello,
I have a question about osmo-fl2k,
the generated binary file using the fl2k grc transmission flow graphs, contains the carrier frequency,
the fl2k_file stream the file to the device, so how the device can transmit these data in that frequency.
I mean how it recognize the frequency to transmit on.
Thank you.
Hi,
I've compiled osmo-fl2k with libusb-1.0.22-1 and this happens when I
tried to start fl2k_test:
feanor@silmaril ~> fl2k_test -s 162e6
Using 6 zero-copy buffers
libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12
Failed to allocate zero-copy buffer for transfer 4
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 15372775 current PPM: -905106 cumulative PPM: -905106
then when I try to connect red and ground output to oscilloscope,
there is no output at all, even if I use fl2k_fm
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)