Jump to content

Bob W Edwards

Members
  • Content Count

    9
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Bob W Edwards

  1. The signal path in my software radio is a complex number double waveform at 96ksamples/s in a range of buffer sizes of 1024, 2048 - 16384 set to suit the users needs. Highest CPU load is with 1024 sample buffers, where a buffer needs to run through the dsp to the speakers every 10.666mS. My prototype receiver uses ordinary LabVIEW queues to transport the data between soundcard daemons and the dsp vi. Should I message the signal path around the place or should I stick with normal queues and message all the rest? Currently the desktop computer loafs along at 7-10% cpu load, but the target tablet is higher at maybe 30% so I'm mindful of not increasing that if it can be helped. I guess the answer is really to try it and see! Cheers Bob
  2. I've added the 'JSON based config load / save' to one of the Actor templates which is working well - the top level Actor ends up with it's config data + that of all subActors and subsubActors and so on in it's internal data - and back the other way too, to initialise controls and internal data. A few questions relating to config file storage preferences:- 1. Do you make top Actor do the actual file save / load or are there benefits in having a dedicated Config subActor take care of that (and maybe more)? 2. Where's the accepted location for such config data to go these days in Windows 7 onwards? I don't want to use the registry. 3. How best to manage configuration of an app whose subActor population can vary from run to run. My software radio needs to support a number of different hardware platforms so will load driver Actors to suit the hardware chosen. The user will want the configuration he's chosen to reappear next session. I guess the subActor responsible for loading the hardware drivers has a little more to do than blindly sending JSON config 'down the tree'. The data may not match those Actors currently loaded. Using Messenger Library so far - good fun.
  3. Sorry, I may have busted the link in the Wiki by editing the programmer's notes above. Could you fix it again and I'll leave it alone ? Bob
  4. Writing the notes forced me to watch the videos closely. I'm going to use the notes as a quick-ref whilst getting started and hoped others might have a go if they had them too. Feel free to make changes/fix wrong stuff in whatever way you like - expect you're a busy man. I'm happy to own the doc and expand it given the info. It's written in libreoffice writer, which exports a good pdf. Now looking fwd to cooking up a few actors. LabVIEW_Messenger_Library_-_Programmers_Notes_v1.7.pdf LabVIEW_Messenger_Library_-_Programmers_Notes_v1.7.odt
  5. Dr James, I'm learning Messenger Library to see if it suits a software defined radio retirement project. To remind me of the basics, I've made a 47 page programmers note. It's free to you if that's useful, otherwise I will keep it private.
  6. Any luck with LibreOffice 5.0.3.2 ? I'm only use 32 bit Windows for now - I guess that means LibreOffice, the SDK and LabView were all 32 bit. Best regards, Bob
  7. Just trying the 'Uno_test.vi' example on Labview 2014 / Windows 7 / LibreOffice 5.0.3.2. Having trouble right off with error code 1172 from the 'Bootstrap' invoke node in 'Create Factory' vi. This is being fed with a .net reference set to 'uno.util.Bootstrap'. If I try and create a similar node, I don't get that resource in the drop-down list. Sounds like I haven't installed or set all I need to with LibreOffice. What did you install and set (paths etc) on your computer please? I'm interested in this because I wrote a small test executive that uses Excel for all data storage. I got pretty good creating my own Excel interface and would like to add LibreOffice support to that. I'd attempted to do that via COM but never got it installed right / LibreOffice doesn't support COM - I never fully fathomed that out. Regards, Bob
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.