A Suggestion or Request

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

A Suggestion or Request

Post by drbob » Fri Aug 01, 2014 3:23 pm

Gentlemen,

I hope that my proposal will be seen as an effort to further our mutual interests by bringing the greatest number of resources to bear on the future of the Nuand hardware and the broader development of software associated with SDR.

Being a relative noob to the SDR realm, I'm finding it difficult to keep track of a fast-moving target. I fully grant that the nature of the beast is transitory by its very nature, so my request is carefully weighed by these points.

It would be significantly helpful to me and I suspect by a number of others, to have some sticky documentation at the top of this thread that can be edited and maintained as development moves forward. Having a reference document for SDRConsole with a "current state" snapshot of proper deployment of the software, and what does/doesn't work based on the current deployment, in a reference location would be awesome. Before anyone thinks that I'm picking on Simon, I'd expand my request to Nuand. As an example, I've recently added the XB200 to the base unit. Fighting my way through the process of making it function has been less than fun, whether on Windows or Linux. The clarity of documentation, spread of the documentation over a variety of forums, conflicting documentation due to revisions and change - each of these works to undermine the fundamental goal.

If there's disagreement, I'd certainly enjoy hearing the reasoning and logic so I might re-think my position.

Bob

Olaf
Posts: 9
Joined: Sat Mar 01, 2014 7:36 pm

Re: A Suggestion or Request

Post by Olaf » Fri Aug 01, 2014 4:46 pm

That's why I suggested bladeRF for dummies. Today I got my xb-200 ( thanks for enclosure :) ) I'm tired of digging thru tons of information..wanted to try it with SDR Console...I see it works...but how ?

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: A Suggestion or Request

Post by jynik » Fri Aug 01, 2014 5:52 pm

Hi all,

Just wanted to offer some comments on this, and some thoughts about where we're going (at least from the tasks I'll be taking on). Granted, I'm just one of the devs, so this can't really be taken as the "official" stance.

As a project we're always learning as we go and looking to improve. Constructive, thoughtful, and well-articulated feedback like drbob's post here is extremely appreciated. I hope to see more of this and will do my best to help guide desired interests in a good direction. While I respectfully disagree about using the forums for any documentation, I hope that you find my comments and thoughts here reasonable.

Away from chaos, toward stability...
I understand that development is moving quickly and that this makes things hard to follow. In an effort address this, we are working towards regularly scheduled releases, with our first stable point scheduled for the end of September. At that point, we're hoping to have the libbladeRF interface quite stable so that we may begin shifting the primary focus on examples, tutorials, and documentation of significantly better quality.

As you can see from the currently available Release Candidate 2 releases will consist of specific FPGA, firmware, libbladeRF, and bladeRF-cli versions. Fresh Windows installers will be built at these points, and package maintainers can track these releases.

On a side note, I will soon be taking over responsibility of the Windows installer, and will look to much more frequent updates of that, generally tracking both the release and release candidates. I'll be posting a new one as soon as I can get the time to finish up some other high-priority tasks.

Centralizing documentation efforts
I also agree that information tends to become spread out across the forums, the #bladeRF IRC channel on Freenode, the wiki, and the codebase. As you can imagine, this become increasingly difficult and time consuming for the devs as well.

While great for discussions and troubleshooting I strongly feel that the forums are not the right place for documentation. I don't think it's the right medium with the right features for this sort of information, and I feel it would cause more work to maintain it well than other mediums.

We're already maintaining community-editable documentation on the bladeRF wiki. The wiki provides a document-format (as oppossed to a discusion thread) that is specifically designed for the job of documentation, providing valuable features such as edit history. GitHub seems to be doing an awesome job of improving this functionality and responding to feedback on making it better.

If there's something that's not up on the wiki that you want, you should feel absolutely free to add it, or even stub out a place for what you'd like to see and how others can contribute to it.

Moving forward with the project, I would like to see us migrate wiki content into some cohesive official (versioned!) documentation. Wiki pages could then point to this informatation and provide a means for the community to supplement it. This official documentation could be shipped in releases in the formats folks know and love. When possible, wiki pages should aim to not duplicate, but instead point to, information already presented well on associated projects.

For example, I personally very much like the way the Yocto project's documentation is laid out and maintained, and the possibility of having documentation rendered like this via ReadTheDocs.org.


Regarding XB-200 support
This has been more chaotic than I would have liked, given that devs are still working on SW support while boards were being shipped as quickly as they could. I know it sucks to wait for something, get it, and then wait some more for application developers to integrate support... but we'll get there.

The Getting Started: XB-200 Transverter Board page on the wiki is where documentation has been started for this. As you can see there, information about using the device in conjunction with GNU Radio (via gr-osmosdr) is listed here. I know jump has been working on integrating support into SDR# and is nearing a stable point in his plugin. Once that occurs, we should get that up on the Wiki as well.

I've been in communication with Simon from SDR-Radio.com regarding XB-200 and general bladeRF.dll issues. I'm looking to get some fixes in ASAP to unblock him on the tasks he has planned with the bladeRF. So stay tuned for more details...


Best regards,
Jon

bpadalino
Posts: 303
Joined: Mon Mar 04, 2013 4:53 pm

Re: A Suggestion or Request

Post by bpadalino » Fri Aug 01, 2014 6:12 pm

I think jynik is on the right track here.

I think the forum is great for getting conversations started and possibly getting community help or opinion, but I think that things like a dummy's guide or better documentation about the current state of the software with regards to the XB-200 or DC calibration or even the block diagram and general information of how the XB-200 does what it does should be placed on the wiki where it can be looked at by many more people, easily linked to other wiki pages and live alongside the code itself.

With that being said, there were some initial questions brought up how does the XB-200 actually do what it does? How was it designed and why? These are great questions which we, as nuand and developers, should be providing you as our customers. I think the forum is a great way to ask the questions, but I think the wiki is the place where the answers should live.

Does that make sense to you drbob and Olaf? To help the conversation, what are some of the pieces of documentation that were troubling that you want to see better documented and that isn't on the wiki already? Did you know we had a wiki or just the forums? Are we doing a bad job organizing the wiki itself?

As always, thanks for your support. I hope you don't view this post as being negative since I do believe this to be a very important goal for us.

Brian

scancapecod
Posts: 83
Joined: Tue Jan 21, 2014 6:38 pm
Location: Cape Cod, Massachusetts, USA
Contact:

Re: A Suggestion or Request

Post by scancapecod » Tue Aug 05, 2014 7:08 am

As a well known bladeRF dummy and a person that runs a Wiki on my website, I will say without hesitation that the Wiki is the single best approach to information. One stop shopping, centrally located, and easily editable.
Scott
Webmaster - Scan New England
http://www.scan-ne.net

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: A Suggestion or Request

Post by drbob » Mon Aug 25, 2014 5:14 pm

I have no problem with the wiki being the reference point for official documentation and useful information to guide the broad base of users.

My respectful suggestion however, would be to see a break-out with the various packages that "talk to" the blade and its addons centrally documented -- or at the least a pointer to the 'official' repository of additional information.

Personally, two different development projects have my interest: Simon's package seems to be geared more toward the "get in, get on, is-it-working" crowd and that's of significant interest to many people, especially those from the Windows environment. The Linux side of things brings more of a tinker's approach and can become quite convoluted quickly - but it also interests me from a completely different standpoint.

I'll return to the wiki and give it a couple more attempts at following the docs to a conclusion and, if I find there are specific areas where we have problems describing processes, I'll work to address them specifically and see if I can help to resolve the matter successfully and document it at the same time.

Incidentally, my reason for suggesting the use of the forum with a sticky is because the subject is changing quickly and what we see today may not be tomorrow.

BTW, I really appreciate the positive, thoughtful responses. Good job.

SDR-Radio.com
Posts: 101
Joined: Thu Jul 25, 2013 3:28 am

Re: A Suggestion or Request

Post by SDR-Radio.com » Mon Aug 25, 2014 11:26 pm

drbob wrote:Simon's package seems to be geared more toward the "get in, get on, is-it-working" crowd and that's of significant interest to many people, especially those from the Windows environment.
Exactly - many people are good at using software and hardware but are untechnical. I really do target a 'Plug-and-Play' approach, so far I've only had a handful of installation problems over ~4 years with my SDR software. I target those who just want to get on with using the hardware which is really all I want to do, I'm looking at a 3m to 4m dish for the back garden, I've found some very nice enclosures for the bladeRF.

When I see some of the hoops you have to jump through to get code maybe working in various Linux distributions my mind goes fuzzy...

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: A Suggestion or Request

Post by drbob » Thu Oct 16, 2014 11:09 pm

Hello all!

Summer has finally ended and the rain has started, putting me back indoors for another 9 months. I turn my attention to the bladeRF and hopes that some evolution has taken place while I was away.

Like a good dog, I downloaded the latest bladerf_win_installer and set about installing same. Pulled the hostedx115.rbf to my favorite place to load from and did so... ah, I was anticipating that command I'd yet to be able to issue: xb attach 200... and received the following error: attach: Invalid expansion board model number. Say what? From the wiki, this was the alleged command to issue and I was so looking forward to miracles, but my optimistic mood was dashed.

What, pray tell, have I done wrong?

I also noted an interesting prompt when I run bladeRF CLI that seems... new?

OMG
bladeRF>

Is that "Oh My God..." you're in deep doo-doo? Or OMG It Lives?

Only mildly annoyed,

Bob

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: A Suggestion or Request

Post by jynik » Fri Oct 17, 2014 2:45 pm

Hi Bob, welcome back!

Sorry for hearing wind got knocked out of your sails - hopefully we can get you back up and running nice and quickly. By the way, I'm happy that you at least speak up so we can get things fixed, so thank you for that. It stinks when people have problems and don't bring them up!

The XB command syntax in the CLI has changed, as a community member pointed out that it was awkward originally. Although we updated the content printed by help xb we failed to update the wiki page. I just updated that info now to match. Below's the aforementioned help output. Admittedly the XB-100 support through the API is still a "TO DO" task; we've been keeping busy on some other bigger tasks (albeit, ones in the guts of the code) over the last few months, but that one is something that I'm interested in tackling.

Code: Select all

bladeRF> help xb

Usage: xb <board_model> <subcommand> [parameters]

Enable or configure an expansion board.

Valid values for board_model:

-   100

    XB-100 GPIO expansion board.

-   200

    XB-200 LF/MF/HF/VHF transverter expansion board

Valid subcommands:

-   enable <board_model>

    Enable the XB-100 or XB-200 expansion board.

-   filter 200 [rx|tx] [50|144|222|custom|auto_1db|auto_3db]

    Selects the specified RX or TX filter on the XB-200 board. Below
    are descriptions of each of the filter options.

    -   50

            Selects the 50-54 MHz (6 meter band) filter

    -   144

            Selects the 144-148 MHz (2 meter band) filter

    -   222

            Selects 222-225 MHz (1.25 meter band) filter. Realistically,
            this filter option is actually slightly wider, covering
            206 MHz - 235 MHz.

    -   custom

            Selects the custom filter path. The user should connect a filter
            along the corresponding FILT and FILT-ANT connections when using
            this option.  Alternatively one may jumper the FILT and FILT-ANT
            connections to achieve "no filter" for reception. (However, this is
            _highly_ discouraged for transmissions.)

    -   auto_1db

            Automatically selects one of the above choices based upon frequency
            and the filters' 1dB points. The custom path is used for cases
            that are not associated with the on-board filters.

    -   auto_3db

            Automatically selects one of the above choices based upon frequency
            and the filters' 3dB points. The custom path is used for cases
            that are not associated with the on-board filters.

Examples:

-   xb 100 enable

    Enables the XB-100 GPIO expansion board.

-   xb 200 filter rx 144

    Selects the 144-148 MHz receive filter on the XB-200 expansion
    board.

As I'm mainly a Linux guy, I had been using this with GQRX and some GNU Radio flowgraphs. I'll have to touch base with Simon to see where he's at -- I last heard he had success and posted a picture on twitter, but is currently waiting on an XB200 replacement, as it sounds like his unit was misbehaving.

Regarding this "OMG" printout -- that's certainly a mystery to me, as grepping the codebase for this does not turn anything up. Does it show up like that every time you run the CLI?

I really don't care for people putting stupid debug nonsense like that in code and certainly would have removed it if I had seen it. I'm wondering if this was somehow introduced by the person currently creating the Windows installer. I'll get out my wiffle bat and look into it.

Best regards,
Jon

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: A Suggestion or Request

Post by drbob » Fri Oct 17, 2014 11:45 pm

Awesomeness...

IMHO the change to the command structure seems logical - "enable" makes sense to me.

For fun, I've attached the window capture from the cli, mostly to impress on other viewers that I'm not entirely crazy, but also to be "the guy" with something unique and puzzling... LMAO...
omg.png
I enjoy getting a new toy, playing with it a short period of time and then allowing the idea to sink into my aging brain for a bit. This lets me form a meaningful idea and approach to taking a project on so that I can begin asking questions that are cogent while illuminating my complete lack of foundational understanding. My sincere apologies to the community as I stumble down the path I see before me, in advance. I'm not a programmer, but I believe I have a decent grasp of the unit's capabilities. I sincerely wish to see the blade evolve into an ever more useful tool in our mutual toolboxes. To that end, I'll be asking a lot of questions as a noob to the programming realm as I attempt to implement some of the ideas - always hoping others might see value in where I'm going and 'chip-in' toward a common, useful, module.

For my first trick, I'm contemplating an always useful tool for radio nerds: a TDR. Anybody else get a warm, squishy feeling about that idea, or is my brain baked in awful-sauce?

Bob

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: A Suggestion or Request

Post by jynik » Sat Oct 18, 2014 9:51 am

Bob,

I just ran the installer on a Windows machine and am seeing the same thing. I'm extremely confused as to why the installer is shipping something with what I assume to be a debug message, as it should be built directly from the git repo (which does not contain such debug output), without changes. I will get to the bottom of this and request that an updated installer be uploaded to the website.

Also, note that you no longer have to manually load the FPGA, unless you want to reload it with a different FPGA than what shipped with the installer. When libbladeRF opens a device, it will search %APPDATA%/Nuand/bladeRF and the installer location for FPGA images to load, if the device isn't already loaded. To verify this, try plugging in the device and running the CLI without the 'load fpga' command. Note that the LEDs will light up, indicating that the FPGA is loaded, and that you can run commands like, 'print samplerate' and 'print frequency'.

Best regards,
Jon

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: A Suggestion or Request

Post by jynik » Sun Oct 19, 2014 3:38 pm

Hi Bob,

The bladerf_win_installer.exe should now be updated with the appropriate release versions of things (i.e., that don't contain silly debug messages). Try that one -- it should be less spastic about having an FPGA loaded. ;)
I enjoy getting a new toy, playing with it a short period of time and then allowing the idea to sink into my aging brain for a bit. This lets me form a meaningful idea and approach to taking a project on so that I can begin asking questions that are cogent while illuminating my complete lack of foundational understanding. My sincere apologies to the community as I stumble down the path I see before me, in advance. I'm not a programmer, but I believe I have a decent grasp of the unit's capabilities. I sincerely wish to see the blade evolve into an ever more useful tool in our mutual toolboxes. To that end, I'll be asking a lot of questions as a noob to the programming realm as I attempt to implement some of the ideas - always hoping others might see value in where I'm going and 'chip-in' toward a common, useful, module.
I just wanted to come back to your comments here, as our earlier discussion focused on how we can all share and expand our knowledge base (with respect to documentation).

As you already know, we're still have our work cut out for us in terms of creating sufficient documentation for both programmers and non-programmers alike. Admittedly, at this point, using the bladeRF for cool and new things is going to be more challenging for the latter. (Although, Robert's MATLAB and Simulink support should hopefully make the device more accessible to people familiar with those tools!)

Our community currently contains a breadth of different types of people, including (1) those with lots of RF and radio experience but not much programming experince, (2)people with software development experience but are new to the RF realm, (3) folks who are experience in both realms, and (4) newcomers to both relams. Below I'm somewhat just "thinking aloud" about how people from these different categories might work together well...

I truly believe that all of the above can participate in making the bladeRF into an ever more useful tool, to use your words. Perhaps one way we can achieve some good collaboration is by having people with some of the RF knowledge present concepts, resources, reading material and draft some informal specifications for what they want to create/implement. The folks with some programming knowldege can produce some examples or associated code snippets for concepts presented in said spec. We rinse and repeat, with both parties diving out of their comfort zone, and perhaps after some iterations we'll arrive at something fun and interesting?
For my first trick, I'm contemplating an always useful tool for radio nerds: a TDR. Anybody else get a warm, squishy feeling about that idea, or is my brain baked in awful-sauce?
It might be worth starting a new thread on this that's soley focused on TDRs. In fact, with respect to what I mentioned above, it might be fun if you could share some of your knowledge on the topic, point people to some good resources, and outline an informal specification for how you'd like it to operate, and where some little divisions of tasks might lie. By breaking the project up into smaller, tangible tasks, it might be easier to get people interested and involved, as well as make the whole thing appears thing less nebulous, as new projects often tend to feel.

Cheers,
Jon

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Re: A Suggestion or Request

Post by drbob » Mon Oct 20, 2014 4:38 am

Ahhhh... <- the sound a guy makes when he does the last maintenance-oriented tower climb of the year and settles into a nice warm bath. Yesterday was that day for me... :mrgreen: That buys me about 8 months of rain where I am (I live in a rain forest. Seriously.) This allows me to get back to some of my projects, including the bladeRF.

Of your choices, I have decent RF skills and have been servicing radio equipment (and many other forms of electronics) in excess of 35 years. (Having put that in writing, I suddenly feel very old... :lol: ) Technical skill in much of the computer realm isn't a problem, except that I've never taken to programming beyond BASIC and some unique interpreted languages to get odd jobs done. Learning the programming realm seems daunting to me, and I'm old enough that I just don't know if there's enough brain-space available to capture the knowledge I need to become "decent" at development. That doesn't mean I'm lacking for ideas, however.

I think the idea of a thread on TDR is fine - but I'm prone to express my broader idea of an RF toolbox and define some of the tools I can see the bladeRF providing the community. As I've said before, I stepped into the bladeRF for two reasons: I'm a ham and saw the bladeRF as a potentially useful SDR for working in the amateur bands; I see the potential to reduce the size of my Motorola service monitor to something manageable. (If you've lugged a service monitor up a mountainside, you know what I mean... :cry: ) I've been playing (lightly, at this point) with Linux solutions for accessing my bladeRF and realized that many of the resources found on a service monitor can be developed in a modular fashion for GNU Radio. What were "menu keys" on a service monitor could be similarly arrayed on a computer screen to pull up various functions. Clearly I was on a useful track as I found CTCSS encoders and decoders, and the always present spectrum analyzer takes center stage. Coolness factor? 9.5

Honestly, my only concern so far is accuracy - NIST traceability clearly isn't possible at this point. Or is it? Even so, is it "good enough" to make this a valuable tool that could evolve over time? I suspect so.

As I work with the bladeRF and get a better handle on this new-fangled radio box that just blows my mind (do you younger folks realize how cool this SDR stuff is? How really cool this bladeRF is? If you don't find yourself amazed by these two little circuit boards, you are a hard man...) I'll do my best to provoke, inspire and encourage people to communicate more on the blade - I believe that's in our mutual best interest.

I'm curious - to date, how many of each of the boards have been sold/distributed? How large is the potential base of participants to the discussion?

Jon - I'll pull the latest package down and run it (OMG really didn't bother me nearly as much as it bothered you... :lol: ) and I'll start putting up some ideas that are bubbling in my brain and see if we can get some traction. I think we're onto something here. I don't know what the larger goal of Nuand is, or what your resources are, etc., but I figured I'd toss out an idea that might have merit: One of the groups that I've been paying attention to is Hak5 - they seem to have a presence on the 'net and are inspiring people to experiment. Their people are young and energetic and part of the "cool crowd" (damn, in my youth we were called nerds and they threw stones at us!) They've been doing quite a bit of proselytizing on the subject of SDR dongles... Would it be worthwhile to reach out to them, provide them with some tools that could advertise more of the Nuand project, thereby encouraging further development and participation? http://hak5.org/ Just a thought. :idea:

drbob
Posts: 39
Joined: Sat Mar 29, 2014 11:22 am

Taking another stab at this ...

Post by drbob » Wed Mar 09, 2016 9:17 pm

bladeRF.png
New computer, some time off from the grind, and wanting to get back to the bladeRF project.

Fresh Windoze install, machine happy, so I grab the software from the official GitHub site (Windows Installer) and poke away. After install, I get the image (attached) and I wonder why I see no devices when I probe... Hmmm... I'm obviously talking to the unit, loaded an fpga, it is talking back to me...

I try to load up a clean install of Simon's SDR Console version 2.3 build 2381 - Search for bladeRF, "Nothing Found". Try a crappy dongle, sees it and talks to in fairly well.

I'm bound and determined to make this bloody thing work! LOL

Suggestions?

Bob

jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: A Suggestion or Request

Post by jynik » Thu Mar 10, 2016 9:13 am

Hi Bob,

Welcome back!

The latest latest (currently beta) Windows installer and an updated Windows installer guide can be found on the Nuand support page.

From your bladeRF-cli screenshot, it looks all is well because:
  • You were able to load the FPGA image. This tells me that bladeRF-cli successfully opened up the device. You probably see a blinking LED on the board after the "load fpga" command completes. This is good.
  • Your 'info' output looks good.
  • Your version info looks good. That newer installer I linked should get you the latest and greatest versions, if you'd like.
  • You executed the "xb 200 enable" command successfully
I bet you should be able to issue commands such as "set rxvga1 10" and "set frequency rx 462.25M".

It's interesting that probe can't find the device you clearly have currently opened. This works fine for me in Linux, but I see a similar issue in Windows. (In the latest code, I see libusb return a "insufficient permissions" error code, which is even weirder.)
I'd say this is harmless to your underlying SDR Console problem, but I have opened an issue tracker item to investigate this.

Now, onto the problem at hand...

Do you have the bladeRF-cli open when trying to run SDR Console? Remember, that only one program can lay claim to the bladeRF at a time; other's won't see it as being available.

If that's not the issue, could you share a log from Simon's tool? GIven that the CLI can talk to the device, we might have to have you ask Simon's support group if I don't see anything in that log.

Post Reply