Re: [USRP-users] Reset EEPROM IP Addressess x310

[Qing Yang via USRP-users]

Hello Brian,

I found your post on the USRP-user mailing list
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-September/026528.html
I also got the same error with you, do you find solutions to this issue?

In my case, the command "usrp_burn_mb_eeprom" did not even work as below

sdrn@sdrn-OptiPlex-9020:~/rfnoc/lib/uhd/utils$ ./usrp_burn_mb_eeprom
--args="type=x300,serial=3104FBD" --values="ip-addr0=192.168.10.3,ip-addr2=
192.168.30.3,ip-addr3= 192.168.40.3"
Creating USRP device from address: type=x300,serial=3104FBD
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-ofdm-408-gf3a40f9a]
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[WARNING] [X300] Duplicate IP address 192.168.40.2 found in mboard EEPROM.
Device may not function properly.
View and reprogram the values using the usrp_burn_mb_eeprom utility.
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/sdrn/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl::wait_for_ack(bool)
  at /home/sdrn/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197

Error: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response
packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl::wait_for_ack(bool)
  at /home/sdrn/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197


-- 
Best regards,
Qing
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Command inside streaming

[Андрей 1 via USRP-users]

Hello
Can I use uhd_usrp_set_rx_freq between UHD_STREAM_MODE_START_CONTINUOUS and
UHD_STREAM_MODE_STOP_CONTINUOUS.Another question is about using
uhd_usrp_get_time_now inside streaming.Let's say I need to switch the antennas.
The B210 board does not have a GPIO and then I use an external switch and 
request
the time using uhd_usrp_get_time_now.But I need to call this command in the
stream before uhd_rx_streamer_recv so that then comparing the metadata time to
find the data corresponding to the switching time.
Can I use any commands at the time of streaming?
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Command inside streaming

[Marcus D. Leech via USRP-users]

On 03/21/2018 07:25 AM, Андрей 1 via USRP-users wrote:

Hello

Can I use uhd_usrp_set_rx_freq 
between UHD_STREAM_MODE_START_CONTINUOUS 
and UHD_STREAM_MODE_STOP_CONTINUOUS.

Another question is about using uhd_usrp_get_time_now inside streaming.
Let's say I need to switch the antennas. The B210 board does not have 
a GPIO and then I use an external switch and request the time using 
uhd_usrp_get_time_now.But I need to call this command in the stream 
before uhd_rx_streamer_recv so that then comparing the metadata time 
to find the data corresponding to the switching time.


Can I use any commands at the time of streaming?

Thank you



YES, absolutely.

Streaming and configuration commands are separate, and you don't need to 
stop streaming to re-tune, or change gain, or switch antennas, etc.







___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Spikes at beginning and end of transmission

[Marcus D. Leech via USRP-users]

On 03/21/2018 03:51 AM, Brais Ares via USRP-users wrote:

​Hi,

I can see a similar spike, a few microseconds long, at the beggining 
of each transmission (see figure attached).
However I'm not using a B2xx, but a *E310*. Could this also be a 
hardware problem or just its normal behaviour?


Regards.
Brais.​
Small transients at the beginning and end of transmissions are pretty 
normal -- with both analog hardware and DSP contributions to the

  phenomenon.

The various pieces of analog hardware (mixers, switches, amplifiers, 
synthesizers) cannot reach steady-state operation instantaneously, so 
there will
  always be some transient from that.  Further, the filters in the DUC 
chain will necessarily experience a transient as new data is loaded into 
them that
  is completely unrelated to any previous samples--they will be 
processing a discontinuity in signal, and there will be some transient 
response as a result.







2018-03-15 20:56 GMT+01:00 Michael West via USRP-users 
mailto:usrp-users@lists.ettus.com>>:


Hi Thomas,

This is a known hardware issue with earlier revisions of the
B200mini and has been fixed on newer versions.  Please contact
supp...@ettus.com  and they can help get
the boards reworked.

Regards,
Michael

On Sun, Feb 25, 2018 at 6:54 AM, Thomas Teisberg via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

I'm sorry, which thread are you referring to?

I have tried implementing the changes in the thread I
originally linked to and it doesn't seem to have made any
difference.

Best,
Thomas

On Feb 25, 2018 4:52 AM, "Steven Knudsen" mailto:ee.k...@gmail.com>> wrote:

Hi,

This is a known problem with the B20xmini. Have a look at
this thread and then follow it up.

You are right, you are seeing caps charge and discharge,
basically.

Since I made the changes myself on my units, I am not sure
where things were left with Ettus and their policy for
fixing the problem. But I can say that once you make the
changes, the transients are gone and the minis work really
well.

regards,

steven


On Sat, Feb 24, 2018 at 3:25 PM, Thomas Teisberg via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:

I'm working on a radar project that requires sending a
series of short pulses. Looking at the pulses on a
scope, I'm seeing large voltage spikes at the
beginning and the end of each transmission.

As shown in the attached screenshot, before the
transmission starts, there is a 90 mV spike lasting
about 10 us. After the transmission, there's a -25 mV
spike lasting about 20 us.

The setup for this is simply a USRP B205mini-i
connected to a 50 ohm input on a scope through a 30 dB
attenuator. The signal is at 435 MHz with the scope
sampling at 20 Gsps.

Our initial thought was that we must be seeing some
effects of some of the RF frontend components turning
on and off. I found this previous mailing list post
and tried the suggested fix in b200_impl.cpp but
nothing changed:


http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-January/012269.html



Any ideas why we might be seeing these spikes or what
we could do about it? Does the fix suggested in the
above mailing list post still apply to the current
codebase?

Thanks,
Thomas

___
USRP-users mailing list
USRP-users@lists.ettus.com


http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com






-- 
K. Steven Knudsen, Ph.D., P.Eng.



___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Accessing the device tree through the UHD C API

[Janos Buttgereit via USRP-users]

Hello everybody,

here at FH Münster University of Applied Sciences we are successfully using the 
UHD C++ API for SDR projects that require high performance. 
Now I’m about to write our own SDR interface framework that allows us a more 
modular approach, e.g. an abstract SDR Interface class with a range of derived 
classes encapsulating different I/O interfaces such as USRPs but also file 
sources and sinks for easy simulation and verification and maybe also drivers 
for some future custom I/O Hardware. This should help us to close the gap 
between the prototype and the final application that might run on an embedded 
platform.

For that reason it’s desirable to not strictly depend on the UHD library at 
link time but have the option to detect if UHD is present on a platform at 
runtime and then dynamically load the library through dlopen. Obviously this 
only works for the C-API. First tests of this approach were successful, we are 
now able to interact with our USRPs without having any dependency to the 
original UHD headers in our codebase as well as having no need to link to UHD 
at build time. Quite nice!

The only thing that’s missing at the moment is the ability to access the device 
tree through the C API. As our framework should also contain some functionality 
to check the exact hardware configuration and abilities at runtime to design a 
(graphical) user interface thats robust against applying invalid settings, this 
feature is really important.
Now my first question is: Did I overlook some capability of the C API to get a 
full report about the device tree?
If not, my second question would be: Is it either possible to contribute to the 
UHD project to develop such a feature or is it possible to ask Ettus to 
implement this feature in some way?

There are various options I could think of, ranging from building a real C API 
for the device tree over to some extern "C“ declared functions that give access 
to the C++ based device tree (that would require to implement the device tree 
class and dependency into our code base, which would be okay for me) or to just 
parse the complete tree into a json or xml string that could be accessed 
through a simple C function and then could be read and parsed into a custom 
structure at my side.

Any thoughts on this are highly appreciated!
Best,
Janos Buttgereit
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Command inside streaming

[Андрей 1 via USRP-users]

Ok.
But when I frequently call uhd_usrp_set_time_now sometimes I get UHD_IO_ERROR
error after which there is no data and I have to close and open the device.
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Command inside streaming

[Андрей 1 via USRP-users]

Sorry. I was wrong. uhd_usrp_get_time_now

Thank you
 Пересылаемое сообщение 
От: Андрей 1 
Дата: 21.03.2018, 17:34
Кому: Usrp Users 
Тема: Command inside streaming
Ok.
But when I frequently call uhd_usrp_set_time_now sometimes I get UHD_IO_ERROR
error after which there is no data and I have to close and open the device.
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] 2x RX/TX Transceiver

[Victor Petrescu via USRP-users]

Hi there.

I have a usrp device, namely B210 and i would like to know if it is
possible to make a dual transceiver. The think is that i want to receive
two different frequencies and transmit them on other two frequencies.

In other words, i would like to make a repeater of two frequencies. I
managed to do this repeater for one pair RX and TX/RX but i cannot do it
for two pairs of frequencies.

I tried something, but after i run i get this error:

UHD Error:
The receive packet handler failed to time-align packets.
1002 received packets were processed by the handler.
However, a timestamp match could not be determined.
Error: Receiver error ERROR_CODE_ALIGNMENT (Multi-channel alignment failed)


I get this message because the two RX are working just in MIMO and can not
be separated or what it means?

Thank you very much and i wait for your answers.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Command inside streaming

[Marcus D. Leech via USRP-users]

On 03/21/2018 11:44 AM, Андрей 1 via USRP-users wrote:

Sorry.
I was wrong.
uhd_usrp_get_time_now


Thank you

How frequently?  What version of UHD?




 Пересылаемое сообщение 
От: Андрей 1 mailto:andrew4...@rambler.ru>>
Дата: 21.03.2018, 17:34
Кому: Usrp Users >

Тема: Command inside streaming

Ok.

But when I frequently call uhd_usrp_set_time_now sometimes I get 
UHD_IO_ERROR error after which there is no data and I have to close 
and open the device.


Thank you



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] 2x RX/TX Transceiver

[Marcus D. Leech via USRP-users]

On 03/21/2018 09:02 AM, Victor Petrescu via USRP-users wrote:

Hi there.

I have a usrp device, namely B210 and i would like to know if it is 
possible to make a dual transceiver. The think is that i want to 
receive two different frequencies and transmit them on other two 
frequencies.


In other words, i would like to make a repeater of two frequencies. I 
managed to do this repeater for one pair RX and TX/RX but i cannot do 
it for two pairs of frequencies.


I tried something, but after i run i get this error:

UHD Error:
The receive packet handler failed to time-align packets.
1002 received packets were processed by the handler.
However, a timestamp match could not be determined.
Error: Receiver error ERROR_CODE_ALIGNMENT (Multi-channel alignment 
failed)



I get this message because the two RX are working just in MIMO and can 
not be separated or what it means?


Thank you very much and i wait for your answers.

The B2xx use an AD9361 RF chip, which uses a common LO for the RX and a 
common LO for the TX, which means that you can't tune to two frequencies 
with
  large offsets.  You CAN use DSP tuning if the two frequencies are 
close-enough to each other.


More information about that here:

https://files.ettus.com/manual/page_general.html

There is no way to have two distinct multi_usrp objects "talking" to a 
B210  -- the streams *MUST* travel together.


Are you coding just with UHD, or with a GR flow-graph?



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IQ transmission using grc

[Benny Alexandar via USRP-users]

Hi Marcus,

Yes, I added a resampler to upsample by 250kHz and scaled the IQ samples by 
dividing it with 2**16, since each IQ is of 16bit.
With this it started to work.

Now, I want to keep changing the IQ file at run time. I have a lot of IQ files 
in current folder, which I want to use for transmission
for certain time say after running one IQ file for 2 min, change the IQ file, 
this should keep continuing.

I had a look at the python code grc generated, and it basically creates a class 
which initializes with the specified IQ file and creates the connection
and runs.

How do I change this python code so that it can loop over all IQ files in  the 
folder, any example python code available ?

Please help me in setting it up.

-ben



From: USRP-users  on behalf of Marcus 
Müller via USRP-users 
Sent: Wednesday, March 21, 2018 2:10 AM
To: Marcus D. Leech; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] IQ transmission using grc

Hi ben,

also, no USRP can directly deal with a sampling rate as low as 48 kHz –
you'll first have to resample to a rate that your USRP can deal with.
In case of the N210, these frequencies are integer fractions of 100 MHz
i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
128 , an even integer 2 < n <= 256 or an integer multiple of 4 <= 512.

tx_samples_from_file can't resample – you should have been getting UHD
warnings about impossible sampling rates; your IQ file has simply been
played back at a higher rate.

Best regards,
Marcus

On Tue, 2018-03-20 at 12:58 -0400, Marcus D. Leech via USRP-users
wrote:
> On 03/20/2018 12:37 PM, Benny Alexandar via USRP-users wrote:
> > Hi,
> >
> > I have an IQ file sampled at 48kHz and want to transmit through gnu
> > radio. The IQ samples are each 16bit, and stored interleaved in a
> > file
> > ie, IQIQIQIQ... I 16 bit and Q 16bit
> >
> > I tried creating a grc using iShort to Complex block and send to
> > USRP sink block (usrp n210), but the signal received is distorted.
> > Do I need to convert the short values into float -1.0 to +1.0
> > before transmission. Please help in resolving it.
> >
> > I want to use it only through grc and not to use
> > tx_samples_from_file which does the same.
> >
> > -ben
> >
>  You'll need to scale your samples into {-1.0,1.0}
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 Faceplate Screws

[Devin Kelly via USRP-users]

Does anyone know what type of screw driver (or security key or whatever
it's called) I have to get to remove the faceplate for the X310?

Thanks,
Devin
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 Faceplate Screws

[Robin Coxe via USRP-users]

Hi Devin. You'll need a Torx-T8 driver.

You can buy a socket set like this one:
https://www.amazon.com/dp/B019ZSK57K/ref=sspa_dk_detail_2?pd_rd_i=B019ZSK57K&pd_rd_wg=wZFLO&pd_rd_r=WZRD45JZ9JXAQTKBXND9&pd_rd_w=MuS17&th=1

-Robin


On Wed, Mar 21, 2018 at 11:21 AM, Devin Kelly via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Does anyone know what type of screw driver (or security key or whatever
> it's called) I have to get to remove the faceplate for the X310?
>
> Thanks,
> Devin
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Command inside streaming

[Андрей 1 via USRP-users]

My configuration:OS Windows7 x32 UHD version 3.10.3 X300+one twinRX.Sample rate
12.5 MHz. 1 Gbit Ethernet.I switch the antennas and request data from two 
channel
as quickly as possible(~ 20 times per second).

Initially, the function get_time_now works fine but after some time the result
returns an error UHD_ERROR_IO.
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Command inside streaming

[Marcus D. Leech via USRP-users]

On 03/21/2018 02:50 PM, Андрей 1 via USRP-users wrote:

My configuration:
OS Windows7 x32 UHD version 3.10.3 X300+one twinRX.
Sample rate 12.5 MHz. 1 Gbit Ethernet.
I switch the antennas and request data from two channel as quickly as 
possible(~ 20 times per second).


Initially, the function get_time_now works fine but after some time 
the result returns an error UHD_ERROR_IO.


Thank you


Are you creating streamers each time?  Are you destroying them when 
they're done?




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [UHD] 3.11.0.0 Release Announcement

[Dario Fertonani via USRP-users]

No comments on this? It's a major bug introduced in the new release, in my
opinion.

Anybody can replicate it by running the official test file linked below,
when compiled with UHD 3.11 from Ubuntu PPA.

https://github.com/manuts/uhd-examples/blob/master/rx_multi_samples.cpp


Just run it long enough (with proper "nsamps" option), kill it via CTRL+C
while still streaming, then relaunch. It dies instantly with errors like
the following.

[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1fffc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x10006
DError: Receiver error ERROR_CODE_OVERFLOW (Out of sequence error)

In my case I ran the following command, but the nsamps value doesn't really
matter as long as it's long enough for the user to kill the first run via
CTRL+C.

$ ./rx_multi_samples --nsamps 1000


Thanks,
Dario



On Thu, Mar 8, 2018 at 5:30 PM, Dario Fertonani 
wrote:

> Thank you Martin, logging is fixed now.
> However, something must have changes in the rx_streamer behavior.
> Basic receive code that has compiled/worked since the 3.9.x days no longer
> works. This is for B210 under Ubuntu 16.04, g++ 5.4, UHD fro 3.11 from PPA.
>
> The receiver works the first time after B210 boot (and associated FPGA
> image load). Then, after CTRL+C or equivalent interruptions, the same
> binary fails right away with these errors (the SID change at every run)
>
> [ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff6
> [ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfffcfff5
>
> as soon as the recv function is called. This suggests that 1) there's some
> stale state from the previous run, and 2) a B210 reboot clears that state.
> Is there a way to clean that state from C++ API? Or, more in general, a
> way to get the rx_stream to work without rebooting the board?
>
> Thanks,
> Dario
>
> On Thu, Mar 8, 2018 at 12:49 PM, Martin Braun 
> wrote:
>
>> On 03/08/2018 09:56 AM, Dario Fertonani wrote:
>> > Hi Martin,
>> >
>> > Our code doesn't compile on Ubuntu 16.04 with UHD 3.11 from PPA (UHD
>> > 3.10.x works well). This is on "amd64" ark, with g++ that dies out with
>> > a missing header (copied below)
>> >
>> > fatal error: uhd/utils/msg.hpp: No such file or directory
>> >
>> >
>> > I can probably fix the headers with some trial and error, but there's a
>> > deeper question: Did anything significant change in the "msg" API?
>>
>> Dario,
>>
>> everything related to the logging API (msg.hpp falls into this category)
>> was completely re-done between 3.10 and 3.11. I'll refer to the manual
>> page: http://files.ettus.com/manual/page_logging.html
>>
>> ...and this email:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>> 2017-April/024653.html
>>
>> -- M
>>
>> >
>> > Thanks,
>> > Dario
>> >
>> >
>> > On Mon, Mar 5, 2018 at 1:51 PM, Martin Braun via USRP-users
>> > mailto:usrp-users@lists.ettus.com>> wrote:
>> >
>> > Two more comments:
>> >
>> > - Binary installers are currently building and will be made
>> available
>> > shortly on the usual spots: Ubuntu PPA is here:
>> > https://launchpad.net/~ettusresearch/+related-packages
>> > 
>> >
>> > ...and Windows+Fedora binaries will be published here:
>> > http://files.ettus.com/binaries/uhd/uhd_003.011.000.000-release/
>> > 
>> >
>> > (but aren't there yet).
>> >
>> > - Because we changed out dev model, you will need to manually reset
>> > maint branch if you're tracking that on git. The following commands
>> will
>> > work:
>> >
>> > $ git checkout maint
>> > $ git remote update
>> > $ git reset --hard @{u}
>> >
>> > Cheers,
>> > Martin
>> >
>> >
>> > On 03/05/2018 12:20 PM, Martin Braun wrote:
>> > > Hi all,
>> > >
>> > > today we've tagged the release for UHD 3.11.0.0. We found a bunch
>> of
>> > > issues during RC testing, but not enough to warrant another
>> release
>> > > candidate.
>> > > Some of the issues we fixed were actually usability-related, but
>> there
>> > > was an actual bug with the images downloader, which might not
>> properly
>> > > update the correct images after doing git pull, and we found and
>> > fixed a
>> > > bug in the X300 firmware which manifests as the GPSDO not being
>> found
>> > > (if you were running master branch with the X300, we highly
>> recommend
>> > > upgrading).
>> > >
>> > > There is one known N310 issue which is still open as of this
>> release:
>> > > When running UHD natively on the device in a multi-threading
>> scenario,
>> > > it is possible to encounter race conditions which lead to UHD
>> dropping
>> > > command packets. We will be releasing a bugfix release within a
>> few
>> > > weeks to address this issue, along with anything else we might
>> > have missed.
>> > >
>> > > Please find the tag