Have a look at the python struct docs [1]; I think the problem is indeed
that you write 64bit floats, and read 32bit floats; so "f" instead of
"d" I think :)
Sorry to keep you busy this long :)

[1] https://docs.python.org/2/library/struct.html

On 19.02.2016 00:57, Richard Bell wrote:
> Sorry, still not working. Values seem to be either 0 or gigantic. I
> think it's because the single 64 bit value is being written as 8
> consecutive bytes as you said, and I'm not handling that anywhere once
> I read the file into octave. I'll try and figure it out next time I'm
> working on this.
>
> Thanks,
> Rich
>
> On Thu, Feb 18, 2016 at 3:12 PM, Marcus Müller
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Argh, sorry, to_float returns a float64, which of course means
>     that Python's file.write is a bit confused by this request, and
>     it's getting late :/ concentration used to be better.
>
>     So, add
>     import struct
>     where the other imports are.
>
>     Then,
>     self._file.write(struct.pack("d", pmt.to_float(msg) ) )
>     should
>     1. get the 64 bit float from the pmt message,
>     2. pack that into a string object according to the format "d"
>     (which simply says, take a single double and give it to me as raw
>     8 bytes)
>     3. writes that to the file.
>
>     Best regards,
>     Marcus
>
>
>     On 19.02.2016 00:05, Richard Bell wrote:
>>     Sorry Marcus, I'm not familiar with pmts and message passing
>>     things to handle these errors on my own. When I change
>>     "self._file.write(pmt.serialize_str(msg))" to
>>     "self._file.write(pmt.to_float(msg))", I get the following error
>>     in grc terminal
>>
>>     handler caught exception: expected a character buffer object
>>     Traceback (most recent call last):
>>       File
>>     "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
>>     line 73, in eval
>>         try: self._callback(arg)
>>       File
>>     "/usr/local/lib/python2.7/dist-packages/msgtools/msg_file_sink.py",
>>     line 41, in _msg_handler
>>         self._file.write(pmt.to_float(msg))
>>     TypeError: expected a character buffer object
>>     thread[thread-per-block[101]: <block msg_file_sink (47)>]: caught
>>     unrecognized exception
>>
>>     Thanks for the help.
>>
>>     Rich
>>
>>     On Thu, Feb 18, 2016 at 2:55 PM, Marcus Müller
>>     <[email protected] <mailto:[email protected]>> wrote:
>>
>>         Ah, sorry, no, the block just takes the raw serialized pmt
>>         and writes it to a file [1]:
>>
>>         self._file.write(pmt.serialize_str(msg))
>>
>>         You could use python with pmt module to unserialize, but:
>>
>>         if you just replace "serialize_str" with "to_float", this
>>         should give you what you expect. Notice this is really just
>>         experimental; copy the block to your own code. I'll probably
>>         rewrite as something in C++ to make it useful on platforms
>>         without python, too.
>>
>>         Cheers,
>>         Marcus
>>
>>         [1]
>>         
>> https://github.com/marcusmueller/gr-msgtools/blob/master/python/msg_file_sink.py#L41
>>
>>
>>
>>         On 18.02.2016 23:13, Richard Bell wrote:
>>>         I just tested it. I expect to see log scale values of SNR
>>>         coming out of the estimator block. When I look at this
>>>         directly using a function_probe and qt_gui_label in grc, I
>>>         see proper estimates. When I load the file produced by the
>>>         msg_file_snk into octave, I see incorrect values ranging
>>>         from e-40 to e+40. I assumed the msg_file_snk stored values
>>>         as float, so I used the read_float_binary.m script on the
>>>         file to plot. Are we having a type conversion issue here?
>>>
>>>         Rich
>>>
>>>         On Thu, Feb 18, 2016 at 1:33 PM, Marcus Müller
>>>         <[email protected] <mailto:[email protected]>>
>>>         wrote:
>>>
>>>             Sorry, I forgot to git push; could you git pull?
>>>
>>>             On 02/18/2016 10:27 PM, Richard Bell wrote:
>>>>             There is only one block in your git, Variable To
>>>>             Message, and no built in Message File Sink in GR. I'm
>>>>             using gr 3.7.10. How did you see this being used?
>>>>
>>>>             Rich
>>>>
>>>>             On Thu, Feb 18, 2016 at 1:12 PM, Richard Bell
>>>>             <[email protected]
>>>>             <mailto:[email protected]>> wrote:
>>>>
>>>>                 Excellent thanks.
>>>>
>>>>                 Rich
>>>>
>>>>                 On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller
>>>>                 <[email protected]
>>>>                 <mailto:[email protected]>> wrote:
>>>>
>>>>                     Sorry, took a while longer, juggling multiple
>>>>                     mails:
>>>>                     https://github.com/marcusmueller/gr-msgtools
>>>>
>>>>                     use the msg_file_sink :)
>>>>
>>>>
>>>>                     On 02/18/2016 09:35 PM, Marcus Müller wrote:
>>>>>                     From the top of my head, there's nothing that
>>>>>                     does that... yet.
>>>>>                     Let's see if I can hack together something in
>>>>>                     python that does that. Gimme a second.
>>>>>
>>>>>                     On 02/18/2016 09:22 PM, Richard Bell wrote:
>>>>>>                     I want to store the output SNR measurement
>>>>>>                     messages of the MPSK SNR Estimator Probe to a
>>>>>>                     file, but I'm not sure how to transform async
>>>>>>                     messages to a stream to get them into a file.
>>>>>>                     Would someone please recommend a method of
>>>>>>                     doing this in GRC.
>>>>>>
>>>>>>                     Rich
>>>>>>
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     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

Reply via email to