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