
mnoromaa
|
SDK Issues with PCI CardModerator's Note: This thread has been split from here:
Hi,
Thanks for posting this tool! It gave me a glimpse of hope in my struggle with the Nebula SDK.
I have the "zero-length file" problem that seems to have been reported on this forum too. Opening the DigiTV application may sometimes help, other times the capture stops after a few MB.
The problem occurs in the read_property() function, when called from get_data_pci(). The DeviceIoControl() call returns zero and GetLastError() returns 38 (ERROR_HANDLE_EOF). Signal strengths are properly read and displayed on the dialog. I have updated to the latest drivers (3.5.1).
Since opening the DigiTV application helps, I concluded the problem to be in insufficient initializations. I have a card that uses the Zarlink chip.
I've emailed Nebula support, and they've said they have forwarded my findings on to the developers. So far no replies though.
Now I tried your capture tool on my computer and it didn't have this problem! Obviously you do something better than the SDK. Can we have the source, please. I'm even willing to pay for it.
- Mikko
|
HyperReality
|
Unfortunately, our NDA with Nebula prohits me from posting any code.
I know the problem you are refering to, and it will happen with PCI cards with the latest SDK if you have not already run DigiTV since the session started. If you run DigiTV, then exit it, then run the SDK application, then it should work fine.
The ERROR_HANDLE_EOF is returned by the PCI card driver when there is no data currently available in the internal circular buffer in the driver. That is expected behaviour.
All I can suggest is that you contact Nebula again, and ask for the code in the set_bt878_mode() function from the original SDK (this is missing from the publicly released SDK for some unknown reason), then call that function in the init_pci_device() function in PCIDriver.cpp.
|
mnoromaa
|
Thanks for the info! I have now emailed Nebula support as suggested. Hopefully they'll answer soon.
> If you run DigiTV, then exit it, then run the SDK application,
> then it should work fine.
This doesn't work fully in my case. The SDK will then save a few MB of data, then stop with ERROR_HANDLE_EOF.
Do you know if this problem is specific to something in my hardware/software configuration (except for the fact that I do not use the DigiTV application)? I mean, does everybody get the zero length file if they don't start the DigiTV app first? If so, I'm wondering how it is possible that Nebula wouldn't have heard about the problem before...
|
HyperReality
|
The few MB of data is probably just whatever data is left in the circular buffer in the driver prior to you starting your application.
If you do a:
| Code: |
fusion_register reg;
write_property(AUDIO, AUDIO_SYNC_FIFO, ®);
|
just before you start reading from the driver, then you will avoid any garbage that is in the buffer.
(Of course, you first need that missing bit of code that actually causes the card to keep filling the circular buffer in the first place).
It probably depends on what state DigiTV leaves the card in as to whether your app will have any joy. If you had a USB device, you'd be fine.
|
mnoromaa
|
> write_property(AUDIO, AUDIO_SYNC_FIFO, ®);
Yes, this worked. Now I don't get any output even if I start/exit the DigiTV app first.
Still waiting for an answer from the Nebula guys. I assume they handle SDK queries as last priority...
Hmm, just wondering if any Linux people would have the required code in some of their drivers. Perhaps I'll try to dig around a bit.
|
mnoromaa
|
No luck with Linux code. I found initialization code that was similar to the ones in SDK's init_tuner() function, but nothing more than was already done there. I also found other stuff dealing with REG_RISC_STRT_ADD, REG_GPIO_DMA_CTL etc, but they looked very much like the driver's responsibility.
So must keep on waiting for an answer from Nebula.
|
HyperReality
|
| mnoromaa wrote: | | I also found other stuff dealing with REG_RISC_STRT_ADD, REG_GPIO_DMA_CTL etc, but they looked very much like the driver's responsibility. |
Not necessarily.
Hint, hint...
|
mnoromaa
|
Thanks for the hint! However, this kind of "detective work" is simply not for me. I got as far as finding the following operations:
write_reg (VIDEO, REG_I2C_CON, ???);
write_reg (VIDEO, REG_RISC_STRT_ADD, ???);
write_reg (VIDEO, REG_INT_MASK, 0xFF800);
write_reg (VIDEO, REG_GPIO_DMA_CTL, 0x1B);
The last two by themselves didn't work, and the REG_RISC_STRT_ADD needs a DMA address as an argument. Unfortunately I have no interest in digging deeper than this...
I am actually getting very frustrated about Nebula in this matter. I thought their card was top-quality and the software extremely nice, but if they cripple their SDK by removing essential functionality, I am very soon ready to switch to another card.
|
Bill
|
| Quote: | | if they cripple their SDK by removing essential functionality, I am very soon ready to switch to another card. |
It's more likely cock-up than conspiracy. The info your looking for was probably just left out by accident (If Nebula really wanted to keep thing that secret they wouldn't have published a SDK at all).
The developers are almost certainly busy trying to get 3.6 out.
Rumours are that they are shackled to their PCs 24/7 and drip fed with black coffee and liquefied donuts. They're only allowed a toilet break when they have either fixed a bug or added a new feature - There are some mightily stretched colons down in darkest Kent.
|
HyperReality
|
| mnoromaa wrote: | | I am actually getting very frustrated about Nebula in this matter. I thought their card was top-quality and the software extremely nice, but if they cripple their SDK by removing essential functionality, I am very soon ready to switch to another card. |
I'm sorry that you are getting frustrated, but as Bill says, it is simply an oversight on Nebula's part. If you had a DigiTV USB device your application would be working fine.
Unfortunately, although it is just 10 or so lines of code, my hands are tied, and I cannot provide any further information without permission from Nebula. Threats to go to other products aren't going to make any difference - to be honest, after doing this stuff for quite a few years now, I'm well and truly over that sort of thing: I _know_ the grass isn't always greener on the other side of the fence, but I also realise that other people sometimes need to figure these things out for themselves. Hopefully you'll hear from Nebula in the not too distant future and everyone will be happy.
|
mnoromaa
|
Yes, I realize you're both right, Nebula is probably not crippling the SDK on purpose. Anyway, it is a rather big problem with the SDK, that's what frustrated me.
Also, I _know_ that switching to a different card would probably not help. In fact, I've been using TechnoTrend brand of cards earlier, but because of problems with them, I am trying to find a better alternative. Nebula is my current alternative.
HyperReality, do you have any direct contacts inside Nebula? If so, could you please ask them for a permissions to publish those 10 lines of code? I'd image it would be quick and easy for them to give you the permission, as opposed to updating the SDK themselves.
- Mikko
|
HyperReality
|
I've put a request in to the powers that be at Nebula, so I ask that you please be patient while I wait for a response (I believe it is a holiday in the UK at the moment, so it might not be for a day or two).
|
mnoromaa
|
Thanks a lot! I'll wait patiently.
|
HyperReality
|
Here you go.
The following code is copyright Nebula Electronics Ltd, and may only be used in accordance with the usage policy and disclaimer shown at the top of the code files in the DigiTV SDK.
| Code: |
// --------------------------------------------------------------------------------------------
// ---- init_gpio
void init_gpio ()
{
data Low;
data High;
data Data = read_reg (VIDEO, REG_GPIO_DATA );
data Enable = read_reg (VIDEO, REG_GPIO_OUT_EN);
Low = Data & ~CLR_REMOTE;
High = Data | CLR_REMOTE;
Enable |= CLR_REMOTE;
write_reg (VIDEO, REG_GPIO_OUT_EN, Enable);
write_reg (VIDEO, REG_GPIO_DATA, Low );
write_reg (VIDEO, REG_GPIO_DATA, High );
} // init_gpio
// --------------------------------------------------------------------------------------------
// ---- set_bt878_mode
void set_bt878_mode ()
{
data Enable = read_reg (VIDEO, REG_GPIO_OUT_EN);
data Data = read_reg (VIDEO, REG_GPIO_DMA_CTL) & 0xc0ff;
data Interrupt = read_reg (AUDIO, REG_INT_MASK);
DWORD Int_Flags = INT_RISCI | INT_SCERR;
Interrupt &= ~Int_Flags;
Enable |= 0x03;
write_reg (VIDEO, REG_GPIO_DMA_CTL, Data );
write_reg (VIDEO, REG_GPIO_OUT_EN, Enable );
write_reg (AUDIO, REG_GPIO_DMA_CTL, 0x00000000);
write_reg (AUDIO, REG_INT_MASK, Interrupt );
Interrupt |= Int_Flags;
write_reg (AUDIO, REG_INT_MASK, Interrupt );
write_reg (AUDIO, REG_INT_STAT, 0xffffffff );
write_reg (AUDIO, REG_GPIO_DMA_CTL, FIFO_ENABLE |
RISC_ENABLE |
PKTP_16 |
ACAP_ENABLE |
PARALLEL_MODE |
SAMPLE_08 );
write_reg (AUDIO, REG_INT_STAT, 0xffffffff );
} // set_bt878_mode
|
And change PCIDriver.cpp::init_pci_device() as follows:
| Code: |
void init_pci_device ()
{
init_gpio();
set_bt878_mode();
} // init_pci_device
|
All the #defines you need should already be in the existing headers (if not, please let me know which ones are missing).
This should get you going - I'm pretty sure that this is all I added to the TS capture tool to get it going correctly.
If it doesn't, then let me know, and you might want to incorporate the above changes into the SDK, without other modifications, to check that everything is working as it should.
The address to send the Finnish beer and/or spirits is on our website.
|
mnoromaa
|
Excellent!!! Thank you very much!
However, the following #define's are missing:
> FIFO_ENABLE |
> RISC_ENABLE |
> PKTP_16 |
> ACAP_ENABLE |
> PARALLEL_MODE |
> SAMPLE_08
|
HyperReality
|
Add the following to device.h:
| Code: | // ---- Fusion DMA register
#define FIFO_ENABLE (0x01)
#define RISC_ENABLE (0x01 << 1)
#define PKTP_4 (0x00 << 2)
#define PKTP_8 (0x01 << 2)
#define PKTP_16 (0x02 << 2)
#define PKTP_32 (0x03 << 2)
#define ACAP_ENABLE (0x01 << 4)
#define PARALLEL_MODE ((0x01 << 5) | (0x00 << 6))
#define HSS_MODE ((0x01 << 5) | (0x01 << 6))
#define AUDIO_MODE ((0x00 << 5) | (0x00 << 6))
#define DDF_04 (0x04 << 8)
#define DDF_08 (0x08 << 8)
#define DDF_15 (0x0f << 8)
#define DA_ES2 (0x01 << 13)
#define SAMPLE_16 (0x00 << 14)
#define SAMPLE_08 (0x01 << 14)
#define NEED_SYNC (0x00 << 15)
#define NO_NEED_SYNC (0x01 << 15)
#define MSB_FIRST (0x00 << 21)
#define LSB_FIRST (0x01 << 21)
#define RISING_EDGE (0x00 << 23)
#define FALLIMG_EDGE (0x01 << 23)
#define SOURCE_STV (0x00 << 24)
#define SOURCE_SFM (0x01 << 24)
#define SOURCE_SML (0x02 << 24)
#define SOURCE_SMXC (0x03 << 24)
|
|
mnoromaa
|
Great! It works perfectly now!
Hopefully others coping with the same problem can find this thread. At least I googled with many function and constant names that are now mentioned here.
And hopefully Nebula can fix their SDK at some point... (still waiting for a reply to my initial query from them, by the way).
|
HyperReality
|
| mnoromaa wrote: | | And hopefully Nebula can fix their SDK at some point... (still waiting for a reply to my initial query from them, by the way). |
The SDK will be updated in due course. They also know that I was taking care of you, and that's probably why they haven't responded directly.
|
|