2012-08-29

building USB power measurement equipment

USB power measurement


USB power measurement set-up


It is generally good to know what is consumed power all the time during USB driver development, especially because power is drained from the very limited capacity USB bus. Reliable testing of power management features  without a measurement equipment is also quite impossible.

Sometimes it is nice to compare Linux driver and Windows driver from the power consumption point of view. It is good indicator that something could be wrong if your driver is eating more power on Linux than on Windows in similar use case.  Undesirable power usage is always kinda problem, especially when device is running on battery. The other problem is heating. USB devices and chips are small and there is no heat-sinks used. Over heating could cause stability problems or even break your device in worst case.

old USB power measurement set-up
Problem with that old set-up was bad cable and cheap multimeter. Cheap unshielded cable causes communication errors with some USB-bridge chips, like Afatech AF9015. Resolution of that multimeter meter was also too low, 3.5 digit / 10A scale. Use always good quality shielded cable and multimeter which could display more than 500mA in reasonable scale.



testing wiring before cover install
Could you see the mistake in that picture? .... Meter was set to DC A whilst red cord is connected to DC uA/mA hole. Unfortunately it show quite realistic values and I installed connector cover using a glue. Later I found it shows negative numbers when meter was set correctly, which means black and red cable are cross connected. It is only visual problem as you can still connect black cable to red hole and vice versa, it was still annoying me... The other small problem I found was red and black cable were not tied together. So I decided open connector again and fix those problems eventually :-)



Pictures
Posted by at 2 comments:
Labels: ,

2012-08-22

My GSoC statistics

It is over now.

Wow, it is over finally. I have to say I was a little bit bored and stressed at the end. Whilst I know almost everything about DVB USB devices, I wasn't very familiar with DVB-core/frontend internals and quite zero knowledge from the V4L interface. Learning new things is something you are doing all the time during Kernel development, but now there was extremely a lot of new things to resolve in long period which was hard. I did some basic DVB driver hacking yesterday, after GSoC was over, and I enjoyed it. It was so easy and funny, just took some random issue, fix it, sent patch to Linux-Media Mailing List (LMML) and continue with new one. No schedules, no plans, just random hacking!


Success and failures

There is clearly one success over the all - DVB USB v2 framework. It is very important for me as I am author and maintainer of remarkably many DVB USB drivers. It was the boost of all that as I was quite pissed off limitations and bugs of old implementation.
Secondly I will list power-management, suspend and resume both DVB-core and DVB USB v2. For DVB USB v2 it is quite perfect and if problems are found there is at least one person who is willing to fix :)
Thirdly I will list failure of SDR API. My initial plan was to add SDR for DVB API, but it was refused and pointed out that V4L2 API is more correct. Without zero knowledge of V4L API I eventually ended giving it up.
The rest changes were quite small, two new DVB API parameters, some random hacks, etc.


Statistics

I collected some statistics, from Git and from my mailbox. Git statistics are collected using git rev-list command:
git rev-list HEAD --after="2012-04-24" --before="2012-05-20" ...
git rev-list HEAD --after="2012-05-21" --before="2012-08-20" ...


Fields in table below are: first number is from community bonding period (2012-04-24 - 2012-05-20) and second number is done during actual Google Summer of Code period (2012-05-21 - 2012-08-20). Consider community bonding period numbers something like what I usually do with my free-time.

Those tags are normal tags used for Kernel Git change-logs and quite self explaining at least for Kernel developers :)



commit tag community bonding period
2012-04-24 - 2012-05-20 		Google Summer of Code period
2012-05-21 - 2012-08-20
Author: 18 147
Acked-by: 1 14
Reviewed-by: 0 11
Tested-by: 0 3
Reported-by: 0 1
non-authoritative Signed-off-by: 7 7


Communication during development is mainly happening on mailing lists and IRC. I read daily quite much mails coming from different lists, no idea even count. I think count of sent mails is more better metric instead. There seems to be 42 sent mails during bonding period and 145 mails during GSoC itself. Those numbers are real mails sent by hand, excluding patch mails sent using Git.

List of patches

Here are the topic of 147 patches I made during actual GSoC period. Few of those are just maintaining changes / fixes for my existing drivers I have to do over the time. Those which are marked as [media] are already merged for the Kernel, last 17 are requested but still waiting.

This is the set I will return.


Posted by at No comments:
Labels: ,

2012-08-15

GSoC is over soon

DVB-frontend statistic IOCTLs

As I mentioned earlier there is some IOCTLs to request signal statistic from the device. Namely those IOCTLs are:
  • FE_READ_STATUS
    • read status flags (am I correctly tuned to channel)
  • FE_READ_BER
    • read  bit error rate
  • FE_READ_SIGNAL_STRENGTH
    • read signal strength
  • FE_READ_SNR
    • read signal / noise ratio (signal quality)
  • FE_READ_UNCORRECTED_BLOCKS
    •  read broken packets (errors seen in picture)
All of those are valid on certain conditions but not always. For example FE_READ_UNCORRECTED_BLOCKS is valid only when demodulator is locked to television channel and picture is streaming. When device is sleeping it cannot perform any of those and garbage was returned or in worst case even I/O error is raised as chip is unable to communicate.

My plan was first to add some logic to allow IOCTLs according to demodulator status flags (same as FE_READ_STATUS). After some study I found it is quite impossible as current drivers does not report all flags correctly - many times it is just all or nothing. No lock at all or all flags which means demodulator is fully locked and streaming. Due to that I ended up slightly simpler solution, just allow those IOCTLs when frontend is running (not sleeping).

All of those mentioned IOCTLs are optional. Average hardware could report quite likely almost 100% all of those but not always. On the other hand driver writers are lazy or they don't have all the needed information which leads to situation IOCTLs are not implemented. When IOCTL is not implemented error status ENOTTY should be reported. I changed error code to meet that  practice too.


DVB-frontend suspend / resume / power-management

That was maybe third time I am back with suspend / resume / power-management issues during that summer. Earlier I implemented it highly as a part of DVB-USB -framework (that I rewrote largely earlier this summer). Anyhow, logically some suspend / resume functionality belongs more for common DVB-frontend part than routines which are only for DVB-USB devices. So I split relevant parts from the DVB-USB and moved those to the DVB-frontend that all DVB device drivers could take advantage.

These are new routines offered by DVB-frontend / DVB-core:
int dvb_frontend_suspend(struct dvb_frontend *fe)
int dvb_frontend_resume(struct dvb_frontend *fe)

DVB-USB reset_resume

There was also one USB device specific issue which seems to be now resolved. USB driver model offers 3 callbacks for suspend / resume.
  • suspend
  • resume
  • reset_resume
The extra and problematic one is reset_resume. It is quite similar than normal resume but for some reason (like BIOS implementation / bug) USB has reset during suspend/resume. Fortunately my motherboard has extra USB3.0 controller which did reset_resume whilst the USB2.0 controllers integrated to south-bridge did normal resume. Because of that I was able to test both cases and find out proper implementation.

Common DTV standard parameter validation

There is quite many possible parameters which could be programmed to frontend in order to tune to television channel. Parameters are defined in different standards. All values are not valid for every standard and also different partly parameters are used. I have seen it quite hard to validate parameters and allowed combinations inside device driver. That makes me wonder if some common routines per standard are useful...
After all I added few routines for most common standards, which I was familiar. Those are DVB-T, DVB-T2, DVB-C (Annex A) and DTMB. I didn't added more as it was very time consuming to find out needed information from many specifications. For example DVB-C, there was at least three different papers to look:
  • EN 300 429
    • European Telecommunications Standards Institute
    • main specification
  • ITU-T J.83
    • The International Telecommunication Union
    • some additions (Annex A/B/C)
  • NorDig Unified Test specification
    • NorDig
    • real life requirements for digital televisions
    • for example frequency limits

Working with that task I take note that these are not listed properly even Kernel documentation. Kernel documentation is place where application developers will likely try to find out possible parameters at the very first. There is clear need to document these correctly...


Posted by at 1 comment:
Labels: ,

2012-08-09

Naked hardware #2: TerraTec Cinergy T Stick

TerraTec Cinergy T Stick

TerraTec Cinergy T Stick

Key components:

Afatech AF9035
Infineon TUA 9001


Keywords: TerraTec Cinergy T Stick, Afatech AF9035, Infineon OMNITUNE TUA 9001, AF9033, AF9030, DVB-T, dvb_usb_af9035, af9033, tua9001, Afa Technology, ITE Tech


Afatech AF9035

Afatech AF9035


AF9035 is integrated digital television USB-interface and DVB-T demodulator. Metal box on bottom-right direction from the AF9035 is 12.000 MHz clock source. Black 8 pin chip left from the clock source is 2k serial eeprom (24C02). It is used likely for storing USB ID and other hardware design settings.

Demodulator integrated that chip is AF9033 and it is sold separately too. AF9035 supports dual mode, which means it can feed two television stream at the same time. For dual configuration it is needed one RF-tuner more and 2nd demodulator which is AF9033. Chip needs firmware.

AF9015 is predecessor of that chip and IT9135 is successor.

ITE Tech has acquired Afatech in 2009. Chips starting from IT9135 are manufactured by ITE Tech.

Linux driver:

name: dvb_usb_af9035
author: Antti Palosaari <crope@iki.fi>

name: af9033
author: Antti Palosaari <crope@iki.fi>



Infineon TUA 9001

Infineon TUA 9001

TUA 9001 is very typical terrestrial silicon RF-tuner. Metal box near tuner is 26.00000 MHz clock source.

Linux driver:

name: tua9001
author: Antti Palosaari <crope@iki.fi>



USB interface

IDLE current drain without driver: 43mA





Pictures










 


Posted by at No comments:
Labels: , , , , , ,

2012-08-08

DVB USB v2 on the road!

DVB USB v2 merged to Linux Media master

Beginning from the last week there has been finally some progression about DVB USB v2 stuff I did earlier. It missed Kernel 3.6 schedule but has now merged the Linux Media master which means it will be eventually Kernel 3.7. Mauro Carvalho Chehab reviews it last week and returned back for me as it failed to compile with allyesconfig. I wasn't even aware such configuration target as I build using Fedora's default configuration, which is quite everything as a module. Breaking build is quite no-no because of Git bisect. I was forced to made huge Git rebase operation in order to keep bisect functional. It was set of over 100 patches and I fixed maybe 20 merge conflicts during that rebase. Guess how much wasted time... Positive point is that now I am quite familiar with Git rebase. It is tool that most developers are forced to deal at some point when fixing merge conflicts or some other issues.

After I was fixed allyesconfig problems and ensured it builds after every single patch I resend PULL-request and it was finally accepted. Mauro converted dvb_usb_az6007 driver for that new framework and dvb_usb_lmedm04 from Malcolm Priestley is under the review. I expect to see more drivers soon, because there is some notable problems with old implementation.

DVB-core situation

Time is running quickly and I have only about one week to go with GSoC.

Much is done but much is still to do. SDR API was one thing I was most interested, but unfortunately it goes a little bit different direction than I was first thinking. I was adding SDR support for DVB API but instead wasted time to learn V4L2 API. Have to give it up for now, but likely I am back this topic later this autumn...

Looking the initial list there is still one topic I see important - general validity checkings for frontend side. I will spend rest development time for that, unless something urgent and time-consuming appears from DVB USB side.
Posted by at No comments:
Labels: ,

2012-08-03

Naked hardware #1: DM04 USB 2.0 Satellite TV Box

Prologue

It has long been in mind of mine to start share some photos and analysis from DVB device internals. Actually, I already have done that few times on my Google+ profile, but lets continue here as it is easier to tell what you should see on the picture.
First device is cheap USB satellite receiver, which I bought the reason I can convert its Linux driver to the DVB USB v2 I recently implemented.


DM04 USB 2.0 Satellite TV Box

DM04 USB 2.0 Satellite TV Box

Key components:

Leaguer MicroElectronics LME2510C
Montage Technology M88RS2000


Keywords: DM04 USB 2.0 Satellite TV Box, Leaguer MicroElectronics LME2510C, Montage Technology M88RS2000, DVB-S, DisEqC1.2, dvb_usb_lmedm04, EzTV210 1.1, FORWARDVIDEO


Leaguer MicroElectronics LME2510C

Leaguer MicroElectronics LME2510C


LME2510C seems to be rather standard digital television USB interface. It contains some extra features, like remote controller and PID filtering. Chip seems to need also firmware which is downloaded by the driver.

There is small 8 pin IC near LME2510C, but unfortunately markings are overwritten with blue paint. I can see still numbers 24, likely serial eeprom like 24C02. Usually that kind of eeprom is for storing desired USB ID. When bridge powers-up, it firsts downloads USB ID from the eeprom and connects to the USB bus using that ID.

Black box right side of LME2510C is IR -receiver for remote controller. Metal box, 12.000 MHz crystal, is LME2510C clock source.

Long wires, which goes top-left direction, are USB Rx/Tx to the USB -connector.

There is clearly visible 8 lines to the other chip on left side. That other chip is M88RS2000. As there is 8 similar lines between demodulator and USB -interface like that, it means most likely parallel transport stream bus. It is bus where picture stream bits are travelling from demodulator to the USB -interface.

Linux driver:

name: dvb_usb_lmedm04
author: Malcolm Priestley <tvboxspy@gmail.com>


Montage Technology M88RS2000

Montage Technology M88RS2000

M88RS2000 is quite highly integrated satellite receiver. It integrates LNB controller, RF-tuner and demodulator to one package. Quite often those are all sold as a separate chips. Metal box is 27.000 MHz clock source. Antenna connectors are routed to the that chip too since it includes RF-tuner. M88RS2000 is rather legacy design as it supports only old DVB-S standard, newer DVB-S2 standard is very common nowadays. New version of that chip, which supports DVB-S2 too, is available.

Linux driver:

name: m88rs2000
author: Malcolm Priestley tvboxspy@gmail.com


USB interface

IDLE current drain without driver: 64mA (66mA without external PSU)


Pictures











































Posted by at 12 comments:
Labels: , , , , , , ,
Subscribe to: Posts (Atom)