Mirics MSi3101

Talk about other SDR products like the FunCube, HackRF, BladeRF etc.
Post Reply
erikfinley
Posts: 1
Joined: Fri Nov 01, 2013 8:28 pm

Mirics MSi3101

Post by erikfinley » Fri Nov 01, 2013 8:41 pm

Hi all,

Anyone been looking at the Mirics MSi3101 solution? I'm looking around for a home project and it looks to be just what I need.

I see that a Windows API is available and I've had confirmation from them that Linux, Android and Mac drivers are in testing.

Seems like they've covered all bases, just wondered if anyone has any experience with it?

Thanks in advance,

Erik.

P-40 Warhawk
Posts: 86
Joined: Thu Jun 26, 2014 11:55 pm

Re: Mirics MSi3101 the dongle that didn,t make it and why .

Post by P-40 Warhawk » Mon May 01, 2017 10:23 pm

I don't know if you have seen this but here it is . I found this on Reddit forum , I hope this explains why the Mirics dongle never made it .


Information on Mirics Chipset for General SDR applicationsNews/discovery (self.RTLSDR)

submitted 2 years ago by Mirics

Background

Several years ago, Mirics developed a silicon and software platform designed to deliver a global solution for broadcast TV and radio. To accommodate all of the different analogue and digital standards deployed worldwide, Mirics adopted a SDR approach utilising ‘re-configurable’ hardware for the tuner and with all of the system specific signal processing implemented in software. This solution was widely implemented in PCTV and consumer radio applications and whilst this chipset is now fairly old, it continues in production and will do so for the foreseeable future. More recently, the chipset has been adopted by a range of companies targeting the ‘Ham Radio’ market where the SDR approach seems to be of growing interest. This market is small in semiconductor terms, but tends to have a highly knowledgeable and inquisitive customer base. Despite the fact that Mirics only sells to OEMs and ODMs, we have been approached by a number of users of these Ham Radio SDR platforms with requests for more technical information on the MSi3101. It is extremely difficult for us to answer all of these questions in a comprehensive manner, so rather than attempt to answer all of these questions individually, we felt it may be helpful to post some information on this and other Ham Radio forums in the hope that the information will be helpful and informative.

API

As the chipset was developed to work in conjunction with our own software as a complete system, we didn’t originally anticipate the need to interface to a wide range of third party software packages. Once this need became clear and given the complex and time consuming support requirements, we felt it would be beneficial to develop and document an API that would allow users to control the chipset in a simple way. It is important to stress that some fairly complex software and firmware lies behind this API and the reason why we don’t publish documentation and source code for this is simply because given the small scale of this market, the effort involved and the support requirements that would follow would simply be commercially unviable for us. We are aware that there have been some notable attempts to reverse-engineer ‘drivers’ for the MSi3101 for the open source community. We must stress that unless the libraries have been provided by Mirics, we simply cannot warrant or support them and whilst we have been impressed with what has been achieved here, we believe that bugs do exist within these libraries which impede the full performance of the chipset. It is our intent to provide a full range of drivers/libraries for as many OS platforms as possible, but to do this and fully debug the code takes time, so please bear with us.

Hardware

The MSi3101 is a chipset that comprises the MSi001 (tuner) and MSi2500 (ADC/USB Bridge). These chips were designed to work together and were never intended to work with third party H/W demodulators such as the RTL DVB-T platform.

MSi001

The MSi001 is a multi-band, re-configurable tuner. It was designed primarily for broadcast applications, but the device was architectured and implemented using the latest techniques to emerge from the cellphone chipset space (The Mirics engineering team came from the 2G/3G radio chipset business). As a consequence, some of the techniques used are unfamiliar to people used to dealing with more conventional tuners. First thing to note is the tuner contains no autonomous RF or IF AGC. Instead, the device uses digital gain control for all stages in the signal chain. To obtain the best performance from this tuner, it is essential to ensure that the gain is set correctly in all stages. The reason for this approach is that broadcast receivers require AGC, but there is no single AGC approach/algorithm that will work effectively for all broadcast systems. Our approach therefore was to implement AGC algorithms on a system by system basis in software. All of the plugins/libraries that we provide for Ham Radio applications do contain AGC, but these can be disabled so that the gain can be controlled manually. The fact that we specify gain reduction rather than gain has caused a lot of confusion. This is done this way as it was how the system was developed in the first place. The tuner uses switched gain steps so the gain can be turned down from its default maximum. It is analogous to switching in attenuators. The analogue filters used have a 5th order Chebyshev response with 0.5 dB ripple. This response gives a good trade off between selectivity and differential group delay. This filter should be thought of as a ‘pre-selection filter’ and the double sided bandwidth can be selected to be either 200KHz, 300 KHz, 600 KHz, 1.536 MHz, 5 MHz, 6 MHz, 7 MHz or 8 MHz. The filter response is calibrated to within a 2% tolerance and the cut-off and shape factor are accurately maintained for all bandwidths. The bandwidth specified is the 0.5 dB bandwidth. The filters use a continuous-time approach and have very high dynamic range. Correctly setting the filter bandwidth for a given signal environment allows for optimising the dynamic range of the receiver and the setting of the filter bandwidth should be considered (along with gain) as another variable that can be controlled by the user In addition the filters can be configured to have a low pass response (for Zero IF mode) or a complex polyphase symmetric bandpass response (for the various supported IF modes). You can select IFs of Zero, 450 KHz, 1.6 MHz, 2.048 MHz. All RF ports for the different bands are brought out separately. Several people have asked why we didn’t implement a tracking filter and a single RF port? This was a conscious design decision and the reasons are simple. Firstly by having separate ports, it is possible to use high quality RF filters that give maximum protection for out of band interferers. Secondly the Q of tracking filters tends to degrade at higher frequencies and so the protection they afford drops off as the carrier frequency is increased. Finally of course, as the MSi001 also covers right down to LW (100 KHz), it is not feasible to cover the full range of bands with a single tracking filter. As some people have pointed out, the approach used in the MSi001 does make for a more expensive overall solution when compared to the tracking filter approach, but we believe that it does allow people to optimise performance. The synthesizer used in the MSi001 uses a sigma-delta fractional-N approach with a third order sigma-delta modulator. This allows for very high levels of carrier resolution and allows for errors in the crystal frequency to be trimmed out by the synthesizer itself by applying a ‘ppm correction’ The synthesizer operates roughly between 2 and 4 GHz and successive frequency dividers allow for the generation of the Local oscillator for the various bands. Many people have complained about the lack of operation between the upper end of Band III and the bottom of Band IV. This is an artefact of the main focus for the chipset being broadcast TV and radio and this as there are no broadcast transmissions in these bands, we did not implement a divide by 8 in the LO path. It is unfortunate, but this is a limitation that cannot be overcome without redesigning the device.

MSi2500

The MSi2500 is a dual ADC/USB bridge device. It contains continuous time multi-bit sigma-delta converters with 24x oversampling. The clock rate is adjustable and a fixed rate decimation filter provides a 12 bit output for each ADC. We read on the SDR Sharp Yahoo group forum a claim that the ADC bandwidth is adjusted by decimation and that at the maximum bandwidth, the ENOB is only 4 bits. This is completely false. The ADCs provide 12 bits at all sample rates and the ENOB is 10.4 at the highest rate of 10.8333 mega samples/sec. We originally rated these as 10 bit converters and this has caused some confusion. Our system design for DTV called for a minimum of 10 ENOB ADCs. We therefore designed for 12 bits and achieved better than 10 worst-case. We therefore internally rated them as 10 bit converters as this is what our own system design had called for. It is simply not possible to build a DVB-T receiver with only 4 ENOB. DVB-T uses 64-QAM modulation and DVB-T2 uses 256-QAM. The OFDM signal has a peak-average ratio of around 10 dB, so a back off from full scale of greater than 10 dB is essential. The AWGN performance for error free data for 64-QAM is around 19 dB and so 5 bits represents a theoretical minimum. However, when you factor in other noise contributions, adjacent channel interferers, phase noise etc, you need far more ADC dynamic range and practically speaking, no one can get away with less than 8 bits. We wanted extremely good sensitivity and so set a very low target for our ADC quantisation noise. The decimation filters have a very large number of taps and so no additional filter of the IF signal is necessary before demodulation.

In summary, the intent here is the provide information that is helpful to interested parties and the correct some of the misinformation that has been disseminated about this chipset. We hope this information is helpful to this community and we wish to assure you that it is our intent to continue to support this small but growing market.

11 commentsshare

all 11 comments
sorted by: best

[–]Jengal 2 points 2 years ago

Since these chips were designed for TV, are there any (cheap) TV dongles with the Mirics chip in them that we can buy and play with for SDR? I know the sdrplay uses these chips but it's a bit expensive for me.

permalinkembed

[–]Mirics[S] 1 point 2 years ago

The major focus of this business was integrated solutions for desktop and AIO PC OEMs. We believe that a number of companies such as Logitech and I-O Data did sell dongles based upon these devices, as did some graphics card companies, but we don't know whether these are still available. None of these solutions provide HF band support as they were intended for TV

permalinkembedparent

[–]christ0ph 1 point 2 years ago*

The GR-osmosdr Gnuradio block is a part of an SDR system which both librtlsdr and libmirisdr speak to but they are mutually exclusive. People use your hardware with libmirisdr. They use the RTL2832 dongles using librtlsdr

The Git repository for libmirisdr is at osmocom.org as is the repository for gr-osmosdr which is the hook to gnuradio based apps.

One thing you should know is that people here and on the various other SDR forums were overjoyed when they saw your chipset because it seemed ideal for the kinds of things people here want to do, and the low cost of building hardware using it made it very interesting- with the caveats that were mentioned then.

You can read them yourself-

See http://search.gmane.org/?query=mirics&g ... smocom.sdr

By all accounts it is a winning chip, but many people were frustrated by the lack of an HF input in the first dev board. With all of these kinds of chips, its fairly simple what people who want to extend them need- Documenation of the hooks, not any internal proprietary info, just what's needed to get the best out of the hardware, which ends up being a win win for everybody.

Currently I am experimenting with using an Arduino clone Atmel microcontroller and a USB hub to make up for the lack on the RTL of addressable gpios. If a dongle dev board broke out a number of addressable gpios, which could be spoken to over USB, I could dispense with the external microcontroller.

A dev board that and broke out as much functionality to headers or rf connectors as appropriate to allow the use of external modules, would be a huge plus.

GPIOs could be used is to toggle DC power to an external LNA, to allow DC power for an antenna - that would enable GPS operation with external software like the GNSS-SDR projects'. assuming it came with a good crystal or low cost tcxo. (they evidently can be found for very little, and would add a lot of value)

GPIOs can also be to switch bandpass filters in and out, or toggle a set of relays to switch from receive to transmit in a ham transceiver.

An extensible SDR platform that exposed hardware internals would be a boon to educators everywhere.

...

You should also post to the osmocom-sdr and discuss-gnuradio mailing lists.

permalinkembed

[–]Mirics[S] 1 point 2 years ago

Many thanks for these inputs. We have been aware that people have been somewhat frustrated over what seems to be a lack of support for this market by Mirics. This is simply because the MSi3101 was created for a different market. To compound matters, Mirics has no Ham Radio operators working for the company, so this has been a learning exercise for us. The be frank, this market can only ever be a secondary market for a chipset such as the MSi3101. These devices cost literally many $Millions to develop and the only way to get any meaningful ROI is via a mass market opportunity. That means needing to sell several million devices which we do not believe is remotely possible in the Ham Radio market alone. In the case of the MSi3101 the focus was mainstream broadcast TV and radio. The dongle that we provided as a reference platform was developed with that in mind and as our OEM customers had no interest in AM, we did not implement LW/MW and SW support (despite the native support for these bands within the chipset) as to have done so would have increased the cost of the reference design). Indeed we only added the capability to support these bands in the first place because of the potential that Digital Radio Mondiale seemed to be offering at the time. Once we started getting interest in the potential for the MSi3101 in the Amateur Radio market, we started to undertake software development to help unlock the potential. This takes time unfortunately and our resources are finite, but we are now making progress. We are aware that some of our customers are considering new projects leveraging the chipset and so these inputs on features should be very helpful to them. Mirics will not be undertaking this development work ourselves, but we will be providing support on an on-going basis. Thanks again for these valuable insights

permalinkembedparent

[–]patchvonbraun 1 point 2 years ago

You shouldn't think of this new market strictly as a "Ham Radio" market, but more of a "experimenters" SDR market.

Lots of folks playing with SDR receivers who are not amateur radio operators, and probably never will be. The kind of "casual airwave surfing" that might have been called "the scanner hobby" is quite prevalent in the dongle-scale SDR market.

And there are also (highly niche, mind) folks using this technology for small-scale and amateur radio astronomy.

So, yes, it's small compared to the consumer electronics market, but it's also perhaps more diverse than just Ham Radio.

permalinkembedparent

[–]dxtr64 1 point 2 years ago

we did not implement a divide by 8 in the LO path. It is unfortunate, but this is a limitation that cannot be overcome without redesigning the device.

Any chance a new revision will have it?

permalinkembed

[–]Mirics[S] 1 point 2 years ago

I am afraid not. The MSi001 was originally designed in 2006 and there are no plans to revise the part at this stage. To do so and re-qualify the product would not be even close to being economically viable. One of our customers has managed to minimise the size of the spectrum coverage gap by a very clever system implementation. By this approach, some units will have no gap, but we are unable to guarantee that no gap will exist in all or even the majority of cases.

permalinkembedparent

[–]dxtr64 1 point 2 years ago

By "very clever system implementation" you mean changing the reference clock of the MSI001?

permalinkembedparent

[–]Mirics[S] 1 point 2 years ago*

No, they do something rather different from that and end up using a portion of the MSi001 circuitry in a way that was never originally anticipated to help cover this part of the spectrum. I am afraid that it is not within our remit to disclose the details of what they have done, but we do feel it was very innovative and showed creative thinking.

permalinkembedparent

[–]dxtr64 1 point 2 years ago

end up using a portion of the MSi001 circuitry in a way that was never originally anticipated

The other way is to use the "upconverter" portion to translate the input frequency a bit. Fair enough :-)

permalinkembedparent

[–]_ceuso_ 1 point 2 years ago

Antti Palosaari has some work on Mirics based dongles:

http://blog.palosaari.fi/2013/08/mirics ... river.html

http://blog.palosaari.fi/2013/10/naked- ... 310uj.html

permalinkembed

Post Reply