Hi Jawad,
ahhh you're right, of course! I was missing that the callback actually
is set in the grc xml file to a lambda that calls recv_packet, so that's
where the checking whether the CRC was correct happens :)
So, yes, I think the logic involved here is OK, but Sang Hyuk is still
seeing problems.
So: You say packets for which the CRC is not correct still get accepted.
What does "accepted" mean in the context? as far as I can tell, they
don't get inserted into the output message queue:
def recv_pkt(self, ok, payload):
msg = gr.message_from_string(payload, 0, self._item_size_out,
len(payload)/self._item_size_out)
if ok: self._msgq_out.insert_tail(msg)
because for them, "ok" is "False".
Do they still appear on the output of the packet decoder?
Best regards,
Marcus
On 21.02.2016 15:22, Jawad Seddar wrote:
>
> Hi all,
>
> The packet decoder block uses packet_utils module (namely the
> packet_utils.unmake_packet() function) found in gr-digital.
>
> The crc check occurs in the unmake_packet function.
>
> The logic in that function is correct, what do you think is wrong with
> returning actual == expected?
>
> Regards,
> Jawad
>
> Le 21 févr. 2016 14:26, "Marcus Müller" <[email protected]
> <mailto:[email protected]>> a écrit :
>
> OK, sadly that means I'm even more confused :(
> packet_decoder doesn't have any CRC checking!
>
> Best regards,
> Marcus
>
> On 21.02.2016 14:20, SangHyuk Kim wrote:
>> No! I'm using current version. the link was just for showing.!
>>
>> 2016-02-21 22:14 GMT+09:00 Marcus Müller
>> <[email protected] <mailto:[email protected]>>:
>>
>> Hi,
>>
>> thanks! Now it's clear what you're using :)
>> Is there a reason why you used a link to an outdated version
>> of the file from 2011?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.02.2016 14:02, SangHyuk Kim wrote:
>>> I'm using "packet_decoder" (http://goo.gl/7uVDDa)
>>>
>>>
>>>
>>> 2016-02-21 21:51 GMT+09:00 Marcus Müller
>>> <[email protected] <mailto:[email protected]>>:
>>>
>>> Hi,
>>>
>>> the problem is that the string "packet decoding" doesn't
>>> appear anywhere in the current GNU Radio source code, so
>>> I'm still not sure which block you are using. Also,
>>> crc.check_crc32 is used in two different blocks, so I
>>> can't even tell this way what we are talking about :(
>>> Can you actually make sure twice you got the
>>> letter-for-letter right name of the "packet decoding" block?
>>>
>>> Best regards,
>>> marcis
>>>
>>>
>>>
>>> On 21.02.2016 13:38, SangHyuk Kim wrote:
>>>> Thank Marcus.
>>>>
>>>> "packet decoding" recovers message from received packet
>>>>
>>>> and i got false from crc.py
>>>>
>>>> def check_crc32(s):
>>>> if len(s) < 4:
>>>> return (False, '')
>>>> msg = s[:-4]
>>>> #print "msg = '%s'" % (msg,)
>>>> actual = digital.crc32(msg)
>>>> (expected,) = struct.unpack(">I", s[-4:])
>>>> #print "actual =", hex(actual), "expected =",
>>>> hex(expected)
>>>> /*print actual == expected*/
>>>> return (actual == expected, msg)
>>>>
>>>> 2016-02-21 20:52 GMT+09:00 Marcus Müller
>>>> <[email protected]
>>>> <mailto:[email protected]>>:
>>>>
>>>> Dear Sang Hyuk Kim,
>>>>
>>>> what "packet decoding" are you specifically talking
>>>> about, and could you show us the code you've modified?
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> On 21.02.2016 12:32, SangHyuk Kim wrote:
>>>>> Hi, I transmit simple text file using two USRP N210
>>>>>
>>>>> Tx)
>>>>> file source -> packet encoding -> mod(GMSK) ->
>>>>> usrp sink
>>>>>
>>>>> Rx)
>>>>> usrp source -> demod(GMSK) -> packet decoding ->
>>>>> file sink
>>>>>
>>>>>
>>>>> To make corrupt packet, I tried to modify part of
>>>>> crc check
>>>>>
>>>>> I guess if the crc of received packet doesn't
>>>>> match with original one, receiver would discard
>>>>> the packet.
>>>>>
>>>>> However, I found receiver accepts every packet
>>>>> even if crc check returns 'false'.
>>>>> (I expected receiver accepts packet only pass crc
>>>>> check by 'true')
>>>>>
>>>>> Why it always return false and how can I corrupt
>>>>> packet with other ways ?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> [email protected]
>>>>> <mailto:[email protected]>
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected] <mailto:[email protected]>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
