Revision 877 questions

[zeraphil]

1) Can you briefly describe how the new file saving works? I noticed you made it async, which is awesome, but it isn't writing directly to matlab, correct? Is that in near future plans, did you want me to do it, or something else?

2) I required a few more units, so I was going to make them. Is there any newer revision than 7 or am I good to go.

3) How should I troubleshoot the high BER rate. Just flash to a lower channel? 

[Tim Hanson]

Hey David,

1) New file saving has only been rolled out in gtkclient_tdt. As you
can see, I'm using the C++11 <atomic> feature to eliminate mutexes on
the fwrite & thereby implementing asynchronous file writing. Because
at this point gtkclient_tdt has much simpler files (just snippets and
timestamps), I'm not going to extend / generalize the functionality
just yet.

Matlab is not in the cards at present, as it's not obvious how to
stream to a matlab file. HDF5, which is the underlying format for
more recent matlab versions, can be streamed to, but it seems overly
complicated :-/

2) v7 is the most recent version of the bridge firmware. (hardware
version 10). Transceiver hardware and firmware both at version 9.

3) Yes, flash to a lower channel. And check which channel Wifi APs
are using the area, or if clearwire/sprint have towers nearby. The
nordic radios are tunable to 2.524 Ghz, which (i think) lies within
their spectrum. (Of course, neither emits enough power to go more
than ~ 10 m)

hth,
Tim

[zeraphil]

Sounds good. 

1) Why can't we generalize the async functionality? It seems awesome.

1a) Do you still want the protocol buffer file writing functionality then? It seems streaming to HDF5 is a pain, we'll still need to convert, but it should make the convert much simpler.

2) Alright, I'll have some boards made.

3) I'll actually make a detailed scan and send it to you. Wifi stumbler should be fine for that right?

[zeraphil]

What are your plans for boost multi_arrays?

On Monday, November 12, 2012 4:11:00 PM UTC-5, Tim Hanson wrote:

[Tim Hanson]

On Mon, Nov 12, 2012 at 3:13 PM, zeraphil <zera...@gmail.com> wrote:
> What are your plans for boost multi_arrays?
>
>

So, boost multi_arrays are nice, they do the job well (once you wade
through the torrent of errors and 'helpful suggestions' that GCC emits
on error). Right now they are used for saving state in gtkclient_*,
but the class is general-purpose and can be used for other things, too
-- data coalescing in 'convert' would be useful, though I fear the
memory overhead. Otherwise, nothing is planned atm.

Tim

[zeraphil]

Cool. I wouldn't worry too much about memory overhead in convert, it's not really necessary for it to be super performing.

Anyways, what's the word on the async feature? Why don't you want to generalize the feature just yet?

[Tim Hanson]

Actually, memory overhead is a critical issue if you are recording
full-day 10's of gigabyte experiments (as it was originally designed
for).

I'll eventually get to generalizing the asynchronous IO + using google
protocol buffers. C structures and fwrite are just .. so .. easy,
though.

Tim

[David Schwarz]

Ah, that's a good point. It's probably better to have a streaming solution in that case. 

ostream is easier than fwrite, imo. But that's me and my love of STL. I'll see if I can get around to writing the protbuffer implementation and get that load off you, it's pretty straightforward, you can get later put the serialization on async. atomic is pretty awesome.

On that note, are you considering stl::threads to replace posix threads? or was there some implementation specfic thing in debian that made it shitty? I can't remember.

Regards,

David S.