Status on HF/VHF Transverter?

[scancapecod]

It's April 23 and I haven't heard anyone comment about the transverters yet so I must conclude that none have actually been shipped. I have seen the info on the order page, but other than that silence from the Nuand folks. The frustrating lack of communication continues...unless it's one of the "cool kids" projects, which they seem to always respond to.

Customer support needs to be available for all users of this device with regards to all categories and questions, whether they are of a boring, mundane, or "pain in the ass" nature or not. It is amazing to me that the questions asked in this thread can go absolutely unanswered for such a period of time. I'd rather have them tell me to go screw my annoying self than say nothing at all.

[bpadalino]

The lack of communications regarding the transverter is quite inexcusable. We've been fighting with parts purchasing and a mixup in manufacturing which pushed out the expected dates. It's still not an excuse for being so quiet.

The integration of the board into the main repository is also behind schedule, so the best predictor of when the boards will get into users hands will be when the master repository has the API changes to tell the library that the XB is attached and can tune to the other frequencies.

No one is being annoying. We'd never tell people to shove off. We're appreciative of your support, and I apologize for all the silly delays regarding this transverter board. Part of the lack of communication is embarrassment that it's taken so long, the other part is trying to put out fires on the development/manufacturing side.

As always, if any of you get upset with us and want your money back for the transverter, please let us know and we'll be glad to refund you. I am sorry that it's taken so long, and I thoroughly appreciate you sticking with us while we work through it.

Brian

[scancapecod]

There's surely no need for embarrassment, Brian. As the bumper sticker says "sh*t happens". I think we're all big kids here and we can wait because we know the finished product will be of high quality. It's just the lack of response that is disturbing. I will point out that you have mentioned that it is inexcusable in the past and then not responded thereafter. I also understand that you all have a lot on your plate with this and God knows what else.

I just feel that we need to hear from you and yours regarding any questions that are put forth. After all that's what you created this message forum for. Even a short response that you don't have an immediate answer but will investigate and respond when there's better information would go a long way. You can tell me to pound sand too if you want; I'm a 25+ year veteran of a police department and I've been the recipient of that line - and numerous other more colorful versions thereof - on more than one occasion!

Thanks very much.

[bpadalino]

Trying to be more diligent on responding here and keeping status updates for those in this forum since it's the one with the longest post history.

The manufacturer had a small mishap with a slight change to the board, and we are now looking at another delay from them for actual manufacturing. In the meantime, we're planning on how we want to let the library know how to deal with both the GPIO on the boards as well as understanding which board is attached.

We do not plan on automatically detecting the boards, and will most likely go with a bladerf_xb_attach() function in the library which the relevant functions (either writing xb_gpio() or set_frequency()) will look at and set the appropriate conjugate bits inside the FPGA, etc.

I will try Saturday updates in this thread from now on to keep everyone in the loop.

Brian

PS - Feel free to call me out on them if I don't do it.

[bpadalino]

The mishap on the manufacturing side has been mostly resolved, but prior commitments on their part caused our batch to be pushed back in the queue by a few jobs.

Luckily we didn't have any component losses, but we're still just waiting on getting through the line with the hardware at this point.

The software side of things is slow due to a refactoring that jynik is doing to the backend. The reason for this refactoring is to make it easier to become native (linux kernel, windows API, Cypress CyAPI, TCP/IP, whatever you want) by moving basically all the logic into a common area with a smaller subset of functions.

On the actual transverter software front, the API still needs to be agreed upon and there has been some discussion about changing the NIOS FPGA code to allow for specific user space register locations/devices. There are currently 2 bits appropriated to read or write access which can be shortened to 1 bit, and expand the peripheral access bits to be 3 instead of 2. That should give 256 8-bit locations for 8 different peripherals, 4 of which are already taken: Platform Control GPIO (controlled by the NIOS), Si5338, LMS6002D, VCTCXO. The ADF4351 synthesizer settings and everything regarding that will probably go into the platform control register space, but expanding out this memory space would be beneficial in general.

Hopefully this has been informative.

If there are any developments during the week I'll be sure to post. Otherwise I'll post next Saturday.

Brian

[scancapecod]

When you say you're not going to "automatically detect" the boards does this mean that I - or the software I'm using to control the bladeRF - will have to intervene somehow to activate it? Being the simpleton that I am when it comes to hardware and software technical knowhow I was hoping for seamless operation. I'm beginning to wonder if I bit off a bit more than I can or want to chew given that 99.9999% of my use of this device will be as a simple wideband receiver.

Thanks for providing the updates Brian. It is good to see them, although most of it is over my head. If this doesn't work out for me someone may own a bladeRF for a "nice price".

[jynik]

Being the simpleton that I am when it comes to hardware and software technical knowhow I was hoping for seamless operation.

I don't think you give yourself nearly enough credit.

Brian's summary is very technically dense, so don't let that alarm you. This information is really just a quick, no B.S. rundown of what tasks need to be completed; the low-level details aren't terribly important unless you want to dive into the code. The "backend" task he mentioned that I'm involved in is staged to be integrated into the codebase, and I'll be helping out on these XB-200 items very soon.

When you say you're not going to "automatically detect" the boards does this mean that I - or the software I'm using to control the bladeRF - will have to intervene somehow to activate it?

With regard to using the XB-200, most of the work will still be done under the hood, by libbladeRF (bladeRF.dll). There's still some ongoing discussions and brainstorming about what can/can't be done automagically.

In the most "manual configuration required by the user" approach, I'd envision the "user story" with your favorite SDR GUI would look like the following:

• From the list of devices, select the desired bladeRF. Generally these might be listed by serial number and/or an index (in the order they're detected).
• After selecting the desired device, various configuration options (preferably saved from the last time you used the device) would appear:
  • From an expansion board dropdown, select XB-200
  • After selecting the XB-200, select the desired filterbank from a dropdown. Options are 50-54 MHz, 144 - 148 MHz, 220-222MHz, and User filterbank.
• Click "run" and operate as you normally do. I envision that you should be able to change those filterbank options at run-time.

So in short, I expect that the most work to configure the thing is to say "Use the XB-200" and "Use this filter bank" -- the underlying software will take care of the rest. It gives the user control over exactly what they want...hopefully while being somewhat intuitive. As I mentioned, there's still some thought going into what does/doesn't make sense to do automatically, vs. giving the user full control.

Brian or Robert, please do correct me if any of this seems incorrect.

Hopefully that clearifies things a bit and makes things seem less daunting. As always, people are around here and IRC to answer questions, never hesitate to ask!

- Jon

[cwiener]

[*] From an expansion board dropdown, select XB-200
[*] After selecting the XB-200, select the desired filterbank from a dropdown. Options are 50-54 MHz, 144 - 148 MHz, 220-222MHz, and User filterbank.[/list]
[*] Click "run" and operate as you normally do. I envision that you should be able to change those filterbank options at run-time.[/list]

- Jon

This sounds like a good low user impact approach. The one question I have is about the filter banks. The expansion board will be delivered with 3 filters installed and connectors for a user-supplied filter. This is great for the ranges listed above but what if you are tuning to a frequency (10 MHz for example) which is not covered by one of the filters? Should there be a dropdown item for "no filter"?

BTW thanks Brian for keeping us up-to-date on the transverter status.

Chris

[jynik]

Just to be 100% clear, these drop downs I'm referring to are just some hypothetical way a GUI could be implemented. With something like gr-osmosdr, these options could be specified via the device parameter string list.

In terms of libbladeRF, selecting the aforementioned options really would just trigger function calls to like bladerf_xb_attach(BLADERF_XB_200) and bladerf_xb200_set_filterbank(BLADERF_XB200_FILTERBANK_50_54). (These are just off-the-hip examples...these calls and enums are not finalized.)

To achieve a "no filter" configuration, I think you could select the external user filterbank and just directly connect that path with an SMA cable. Personally I'm not sure if this is the best approach, or if there's a better one.

I didn't want to complicate the example too much, but there is actually another option - bypassing the mixer entirely. Check out the block diagram, you'll see the 3 filterbank paths + the disconnected user filterbank, as well as the bypass path.

- Jon

[scancapecod]

Jon,

Thanks for the clarifications. I'm hanging in there.

I'll be at the mercy of Simon's programming. I expect he'll receive his transverter before I do. I know he's in the midst of a big life change with a major move from one country to another so there will be a delay in building anything new into SDR-Radio. Not sure if gqrx will be updated to work with it either but I have the capability of using it as well with reduced bandwidth from a VMWare Viewer virtual host.

Much to learn. I hope to be able to use it in a transmit capacity at some point as well, but for now it will see continued use as a wide band receiver. With that in mind I would expect I'd obviously just bypass the mentioned filters when listening outside of those frequency ranges.

[bpadalino]

I forgot to update last weekend, sorry.

For this two week update, we've resolved the manufacturing issues and are getting the new batch of boards coming in. Things are looking good. The LO is locking, we're selecting the different bands, and we're just making sure the results are all good.

We're actively working locally on getting the interface in place so software can integrate the lower tuning. The hardest part will probably be switching the filter selection from the 4 different ones available, along with the bypass selection.

Hopefully within the week we will accomplish the following: including the software into the master repo, and giving the thumbs up to complete manufacturing of the rest of the boards. I am not sure when we give them the thumbs up if we will be first in line to be manufactured or if they will put us in the queue. I'll let you all know when that happens next weekend.

Brian

[scancapecod]

As one of the biggest gripers about not getting updates, I'd like to thank you for providing them, Brian. A little communication goes a long way, to be certain. It sounds like good things will come to those who wait.

[bpadalino]

We have received a much better batch of boards and given the go-ahead to our manufacturer to produce them all.

The results are pretty good so far. We configured the board to be in the user filter mode, and connected a normal SMA cable for the user filter. This way, we can look at just normal FM. We updated some HDL and the library (pushed to the github repository as of this morning) and was able to get GQRX to show us a lot of FM stations.

You can see the HDRadio sidebands next to the main FM carriers. I believe, for that image, the conjugate bit was not set. Since we're doing high side injection, the spectrum is reversed so we were not seeing FM at 109MHz here in the US. When we switch into one of the other filterbanks for the amateur bands, the FM band is sufficiently notched right out - so a little worse NF on the front end, but allows you to put a notch right at FM for better selectivity.

Next up would be to put a Hilbert filter in the FPGA so when you are doing direct sampling, you only see the positive spectrum and none of the negative spectrum.

Keep watching the repository for code updates. I'll give another status update when we've received the boards and started sending them out to customers. We will also work with Simon Brown and the gr-osmosdr folks to make sure everyone is able to take full advantage of the different filterbanks as well as better seamless integration for frequency tuning.

Let me know if there are questions or other comments. Like I've said before, if you don't want to wait any longer just let me know and we can refund your money ASAP.

Brian

[Vine]

Hi Brian,

What's new about the transverters manufacturing ? I'm so impatient to receive the board for starting some amateur satellite recordings and some other experiments... And you folks, what have you plan to do with the transverter ?

Vincent

[bpadalino]

Sorry - I have forgotten to post the last Saturday (maybe even two?).

Manufacturing has begun and I believe within a week or two we will be getting all the orders out to people. There was a silly silkscreen error that was the last thing that needed to get updated.

As for software, there are branches up on the github which are the XB-200 host code and VHDL code for the FPGA. This work should come into master by the end of this weekend, and we will update the wiki with programmatic ways on how to tell the driver that the XB-200 is attached.

Some people who are active on the IRC channel and are good with programming have already been shipped their boards and initial tests seem good. Reports are that the normal antenna input can work down to 10MHz with no problems and as good as an HF rig which is both surprising and great.

To prepare, you should get yourself some SMA cables. There are 4 total connections that need to be made if you want to have complete unrestricted access to the spectrum. One is the vertical SMA connections which are available for a custom filter. In this case, it would be a straight SMA cable. The filters on the board are for 50M, 144M and 220M with a decent notch at FM to try to get better selectivity.

The other connection is the IF from the XB-200 to the bladeRF itself. So if you plan on both TX and RX, then 4 cables are required.

Hopefully this weekend I can give another update saying the code is committed and in master along with a new FPGA image released. We have to work with the gr-osmosdr folks to update the device string and tell the driver there is an xb-200 attached.

Thanks for keeping me honest.

Brian