-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Date:2013-08-14
For a number of reasons[0], I've recently changed my email provider
and set up a new OpenPGP key. As a result I shall be immediately
transitioning away from my ten-year old PGP key.
The old key will be revoked very soon, and so I would like all future
correspondence to use the new one. I would also like this new key to
be re-integrated into the web of trust. This message is signed by
both keys to certify the transition.
The old key was:
pub 1024D/AE445B2E 2004-10-25
Key fingerprint = E27B 3AF7 C367 74C2 FFF0 40B7 5BB6 809B AE44 5B2E
and the new key is:
pub 4096R/0E7A0087 2013-08-14
Key fingerprint = AB4C DD88 559B B3AC DF63 DC76 AE2F F214 0E7A 0087
To fetch the full key from a public key server, you can simply do:
gpg --keyserver keys.riseup.net --recv-key 0E7A0087
If you already know my old key, you can now verify that the new key is
signed by the old one:
gpg --check-sigs 0E7A0087
If you don't already know my old key, or you just want to be extra
sure, you can check the fingerprint against the one above:
gpg --fingerprint 0E7A0087
If you are satisfied that you've got the right key, and the UIDs match
what you expect, I'd appreciate it if you would sign my key. You can
do that by issuing the following command:
**
NOTE: if you have previously signed my key but did a local-only
signature (lsign), you will not want to issue the following, instead
you will want to use --lsign-key, and not send the signatures to the
keyserver
**
gpg --sign-key 0E7A0087
I'd like to receive your signatures on my key. You can either send me
an e-mail with the new signatures (if you have a functional MTA on
your system):
gpg --export 0E7A0087 | gpg --encrypt -r 0E7A0087 --armor | mail -s
'OpenPGP Signatures' <smg(a)hush.com>
Additionally, I highly recommend that you implement a mechanism to keep
your key
material up-to-date so that you obtain the latest revocations, and other
updates
in a timely manner.
I also highly recommend checking out the excellent Riseup GPG best
practices doc, from which I stole most of the text for this transition
message ;-)
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
Please let me know if you have any questions, or problems, and sorry
for the inconvenience.
Steve Glass
0. https://www.debian-administration.org/users/dkg/weblog/48
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlILarcACgkQW7aAm65EWy7Y3ACgu55BvaS59A3l41uDsXkrIUMi
a7AAmwTlctyIdAWDj7vXH9InucqIqGlMiQIcBAEBAgAGBQJSC2q3AAoJEK4v8hQO
egCHpJoQAKLyqNRvosqXiiiV4HvxeiiaYlzfkv6CejfynBD5vO4RR+nzim002T7I
ezCmPObO+6PtA0go3qkYn94YIKxqn1RK+ctMmWAF5utAQ0V6bEGMseIwvdzuWt4x
aoaHxdDng1ZaQJO9xS6U/SCm34vg0dQlCW+4sSiMg/GsQ2+wv71wThh81T37DuBX
bDGz53ZMA/wz/W52YJkSaEn+k+R/Js1FSFpNuCvn2NT2wZiWr05H2KKMCUgHitbi
cWA8uFD4Z4EshWJHHlRX3hdB8HygQ8N1rVb83GZjZxMGEUEfVC88ZUSt6al3ACfN
Ix9uM3xbKJ7thrl0NwrvQG/Z+ecmUyjENBeXQBwne86TzVx3E9mgoDdER7pf+zpe
rqXvMSfa+ONSghHkm9u5UCli5/kduG/0gW3eeuqCtXq08c0zJe0NzGsWUSYVNZmI
oeq1erVNpo7zzo7XHGPA8Yq3nfgFPV6A/3ivfmema/J17ngWMtym5CGy8EpJelRv
J4QNRBUGVRKBgrlX+3AvDXvtQznE/NZqE1ugbzGrdimZsxR5d5FcBJU+1+jgZ/OJ
ur//OBHPfDvF15RtiYOCi66IPC5AUrOK0gcw+x/9VHkd6olU7dJDXxx5N58/VNnm
weB+JNY3doQuch4lQVqQ5r484KzfoUS2r7ZC/o/xo2aA6kvanwpZ
=OoMf
-----END PGP SIGNATURE-----
hey,
i made some code to show information from the data units; some in the
c++ (ldu1.h, ldu1.cc, etc) and some in the python (traffic panel). now
when i leave it running for a somewhat extending period of time op25
dies with what i think is some sort of memory error:
*** glibc detected *** /usr/bin/python: free(): invalid pointer:
0xb7698434 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7567ee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb696eadf]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b)[0xb69d67bb]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN19snapshot_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x236)[0xb2ce6de6]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN17data_unit_handler6handleEN5boost10shared_ptrI9data_unitEE+0x54)[0xb2ce5c74]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN16voice_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x66)[0xb2ce8116]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN15op25_decoder_bf14receive_symbolEh+0x18c)[0xb2cffbec]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN15op25_decoder_bf12general_workEiRSt6vectorIiSaIiEERS0_IPKvSaIS5_EERS0_IPvSaIS9_EE+0x4b)[0xb2cffddb]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(_ZN17gr_block_executor17run_one_iterationEv+0xa09)[0xb6aa5529]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(_ZN18gr_tpb_thread_bodyC1EN5boost10shared_ptrI8gr_blockEEi+0x4b1)[0xb6ac7aa1]
/usr/local/lib/libgnuradio-core-3.6.3.1.so.0.0.0(+0xb335b)[0xb6ac235b]
/usr/local/lib/libgruel-3.6.3.1.so.0.0.0(+0x32e46)[0xb6c6ae46]
/usr/lib/libboost_thread.so.1.49.0(+0xb96c)[0xb68f096c]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb76c5d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb75e0dde]
======= Memory map: ========
i omitted the huge memory map. i have no idea what to do with this sort
of back trace. any guidance will be much appreciated.
Cheers,
Matt
hey,
i am having major problems here. i was testing some code i put into the
ldu1 files to get the unit ids. after many installations of the revised
ldu1 files my work was halted. first my grc got stuck on start up. now
it starts and dies in a flash and prints out like a thousand errors that
essentially, i think, say that op25 is not installed; or that it is
installed incorrectly.
i have been trying to remedy this all weekend. i uninstalled and
reinstalled op25 and gr-baz and grc3.6.3. multiple times. i am fresh out
of ideas. i attached the traceback stuff, if you can, please take a
peek. any guidance would be much appreciated.
--
Matt D
------------
Hey,
In the hdu.cc file there is a function 'apply_rs_correction'. I am
interested in finding out how this works. What is confusing me is that
I know it works. But I have been looking at this code and to me it
seems to do essentially nothing???
// apply a different kind of correction
void
hdu::apply_rs_correction(bit_vector& frame)
{
// pre-processor if statement that is *always false* (0 == false)
#if 0
*// so this code is not included in the final compiled program
static itpp::Reed_Solomon rs(6, 8, true);
const size_t rs_codeword[][6] = {
};
const size_t nof_codeword_bits = sizeof(codeword_bits) /
sizeof(codeword_bits[0]);
// the end of the pre-processor if statement
#endif
// and that's it for this function? -- so this function is actually
empty in the compiled program???
}
I am putting comments in the code trying to understand it. What am i
missing here?
--
Matt D
------------
Hey,
I am trying to get a handle on the data in the Link Control Word. The
LCW is 72 bits right? On transmission the 72 bit LCW is serialized into
12 hex bits. And then it is encoded with a (24,12,13) RS code to yield
24 hex bits. The 24 hex bits are then encoded with a (10,6,3) shortened
Hamming code to yield 240 bits total.
Is it known how the bits are serialized? Or better yet is there an
existing function for unserializing/serializing that will work here?
And the Hamming and RS codes: does anyone have functions for decoding
(10,6,3) Hamming and (24,12,13) RS code?
If these decoders do not exist already, where should I start?
Thanks!
--
Matt D
------------
Hey,
Does anyone know whats up with the LCFs??? There are only 2 examples in
the Daniels manual. I have been unable to find out anything about the
remaining LCFs.
Thanks
--
Matt D
------------
I've had some people request that I submit the P25 CAI Wireshark
dissector upstream for inclusion in Wireshark. It makes sense to me
since it is quite stable. Do others agree?
My only concern is that we currently use an unassigned UDP port and
encapsulate P25 CAI in UDP. Should we try to get an official pcap data
link type (DLT) instead? Are there reasons to prefer UDP over our own
DLT? If so, should we pursue standardizing a UDP port number?
Mike
Hi folks,
A quick update: I've added to gr-baz <https://github.com/balint256/gr-baz>
some new OP25 blocks.
I've split up the combined 'Decoder' block into the FSK4 and actual decoder
(simple) parts.
I've also added the traffic pane - you'll see how it fits together in the
sample/OP25.grc
Make sure you back up your old GRC file before you update so you don't end
up in a nasty XML merge conflict!
For those people that aren't hearing any audio, check if the traffic pane is
showing you anything.
For those wondering about talk of patches, instructions are here:
http://wiki.spench.net/wiki/OP25
If you use r307+patch, you can also check the console to see if decoder
information starts appearing to see if valid frames are being detected.
Balint
