Hi!
I've borrowed a Funcube Dongle Pro and tried to use it with
osmocom-tetra. I've manually tuned it to a tetra carrier using the
Qt-GUI, and it I can see the carrier very clearly in the spectrum/fft.
However, I'm getting many more bit errors than with a USRP2+WBX board.
Also, I have the feeling that the WBX has a much higher sensitivity,
even with the FCDP input LNA at 30dB maxed out.
Can anyone confirm these findings?
I'll do some more investigation and report back here.
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)
Hi,
I've modified the usrp2 script to use the UHD gnuradio driver for new USRP
(UHD-only) hardware.
It seems to work with my N200+WBX setup, but gnuradio is pretty new to me, so
there might be some bugs.
Since I'm using the WBX my antenna port is 'TX/RX'.
I'm not sure if this is a good default value, it's configurable though.
Clemens Hopfer
Hi!
For those interested, I've taken apart the case and did some
investigation how the FCDP hardware architecture looks like.
The results are available at
http://tetra.osmocom.org/trac/wiki/Funcube_Dongle
It seems the silicon tuner actually is intended for DVB-T, thus the
bandwidth it can down-convert is _much_ higher. However, the audio
codec that they use can only do 96kHz.
That's actually really sad. I wish they had used something with higher
ADC rate. But it seems like even high-end audio codecs never get you
beyond 196/216 kHz - still insufficient for e.g. GSM.
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)
Hallo Tetra Liste,
möchte nicht unhöflich sein, im Archiv habe ich zum Thema Funcube und dem py Script nichts gefunden. Wer kann mir mehr Informationen geben? Gibt es ein extra Wiki oder einen Blogbeitrag? Screenshots?
Suche mehr Informationen wie ich den Funcube mit dem Script auf einem Ubuntu System einsetze. Danke.
Gruß Markus
Hi!
libosmocore >= 0.3.1 and the current osmo-tetra code will now generate
not only the sending GSMTAP UDP socket, but also a locally-bound receive
socket.
This avoids the manual start of "nc -l -u -p 4729 >/dev/null" or
iptables rules to drop the UDP packets.
The local receive socket is only created if the GSMTAP IP address is a
locally configured address on any of your network interfaces. So
sending it to 127.0.0.1 should work well.
Don't be surprised if you happen to see GSMTAP over IPv6, I'm now using
getaddrinfo() and related functions, i.e. "loopback" may now resolve to
::1 instead of 127.0.0.1
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)
Hi all!
As some of you already know, Holger and I have recently started a new
company called "sysmocom - systems for mobile communications GmbH".
The process of establishing the new company has now formally concluded.
Before some rumours start to spread, we would like to clarify some
points and make sure there is mutual understanding between the Osmocom
community and the sysmocom company.
sysmocom is intended to provide commercial offerings related to the
Osmocom projects. This is not entirely new. Especially on the network
side, people like Holger and I have been doing quite a lot of paid
development to bring those projects forward. We would not have many of
the features we have today, if it wasn't for customers who actually pay
us for development of OpenBSC, OsmoBSC, OsmoSGSN and the various side
projects more targetted at a real network operator like cellmgr-ng,
bsc-nat, gb_proxy - just to name a few.
However, this has always only been freelancing development of Software.
With sysmocom, we want to go one step further and work on hardware
products related to the various Free Software projects. Right now I
don't want to talk too much about unfinished products, but we are
working towards an inexpensive BTS product, we are funding the
prototypes for Osmocom SIMtrace, and we will likely also see stuff like
OpenBSC appliances.
Given our past involvement and exposure into other projects that share
a split Free Software / business set-up, we think we understand very
well where potential issues of conflict between the two sides may be.
Let me make some more clarification what this is not about:
* sysmocom is not about creating proprietary derivates of Osmocom
software. We work on Free Software which is publicly available under
OSI approved and FSF endorsed licenses. We may offer proprietary
hardware and sometimes software - but those are independent projects
from existing Osmocom software.
* we specifically will not have a public and a non-public version of
the same program with differences in features.
* sysmocom is not a VC-funded startup. It's a very small company
run out of personal funds with no intention to take external funding
or grow rapidly. Nobody but Holger and I determine where it goes
and what it does.
* sysmocom does not hold any copyright on the Free Software projects.
The copyrights stay distributed with the major authors such as Holger,
Onwaves, Sylvain, Dieter, Andreas and myself. None of the others have
any affiliation with sysmocom. I have (personally, unrelated to
sysmocom) asked some of the smaller contributors for a copyright
transfer to make sure we could do the AGPLv3 transition, or future
re-licensing decisions without having to ask dozens and dozens of
people. sysmocom does not seek to control the Free Software projects.
* we will maintain a strict separation between the community side of
things and the business side. Unlike some other popular projects, we
will not end up in a situation where the osmocom.org websites will be
full of advertisements and hidden links that lure you on the company
website.
* we will keep a strict separation of naming. Osmocom is for the FOSS
projects, sysmocom for the business. The company will use the term
"Osmocom" only in descriptive context, not as a product name, brand
or for advertisement.
If you do have any concerns, please feel free to share them. However,
I'd like to avoid cross-posting them throguh different mailing lists.
Please follow-up-to openbsc(a)lists.osmocom.org
Regards,
Harald
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi all!
[This message is cross-posted to many lists, please be careful when
replying to it! Think twice if your respones really matters to all
those projects...]
In order to do some better planning for our Camp activities this summer,
I would like to request all people who intend to participate in the
radio village to add themselves to the wiki:
https://events.ccc.de/camp/2011/wiki/index.php/RadioVillage
The list of citizens is auto-generated if you use Person template like
I have done in my user page at
https://events.ccc.de/camp/2011/wiki/index.php/User:LaForge
The large main tent is not really intended as a place to sleep, but more
like a place where we set up our gear and work on the various projects,
similar to what happened at HAR.
Thanks in advance!
--
- 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!
during some work over the last weekend on OsmocomTETRA and reading through
many hours of real-world TETRA captures, I have realized that a lot of the
data we displayed about the higher protocol layers (like MM, CMCE, ...) was
completely bogus.
The reason for it is simple and quite obvious: My old code made the assumption
that the MLE layer is directly on top of the MAC layer - whereas in reality,
there is the LLC layer in between. Not only that, but LLC also takes care
of fragmentation and re-assembly, i.e. we were just printing some general
nonsense.
I've started to fix this in the git master banch and I have some local
uncommitted code that actually implements re-assembly. I've successfully
decoded some NTP/UDP/IP-in-SNDCP-over-TETRA frames from a real network,
but the implementation is a big ugly hack and has many constraints.
I will try to clean this up asap and commit it (maybe even later today).
This posting is JFYI, so you are not surprised if you now get some completely
different output with the same input data.
The good part is that we actually get the CMCE messages that tell us when and
where will be voice frames that belong together, i.e. we can identify start and
end of indivdiual push-to-talk 'segments'. This could be a nice base for
extracting them in a useful format.
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)
Hi!
My name is Marius and yesterday, though I was in a hurry to catch my train
back to HL, I was in Harald's ETSI Tetra presentation. It was great; and I
do have a USRP2, portable power supply, a sailing license (there're these
big coast-guard towers here). Any implications are theoretically of course
at this point.
Just a small question: can one expect legal trouble if... accidently
though... some Tetra signals found their way into a GR cfile onto some web
server and would be shared (here)? Afaik it's not excactly ISM band.
And to the second question: what was the name of the recommendable book,
that was not marketing foo? I'd like to give the cryptanalysis a try, but
before I can say that I have to look at the standards and algorithms.
Did anyone already review that? I know that Stephen Glass of the OP25
project did some research on APCO 25. - Which isn't ETSI.
Best,
Marius
--
pgp id: 0xCCCA5E74, mc - at - sandokai.eu
http://crazylazy.info/blog, twitter: @wishinet
Hi,
To add support for traffic extraction, it's necessary to introduce
some nothing of "state" in the MAC layer (since the DL_USAGE must be
'remembered' to know how to interpret further data) ...
Any suggestion how to achieve that as cleanly as possible ?
Having a global doesn't sound that nice, but passing a struct around either.
Maybe introduce a pointer to a 'tetra_state' in the primitive struct ?
Cheers,
Sylvain
