To make it easier and less error prone when specifying i2c data may I urge you to look again at my suggestion in post #270. The basic idea is to have a set of constants with meaningful names and well defined functions. Such as the multiplication factor for the carrier frequency. Then concatenate them to make the array of i2c data. Then you're not staring at a string of 0s and 1s wondering what they all do and trying to spot obscure errors.
More generally let computers do what they are good at doing while allowing humans to things they do well
Thanks Frank,
Yes, that is the information you sent me.
I fully understand which bits in the modulator bits sequence I should set to what. No problem there. The datasheet is clear on that.
Thanks for your email. I'll study it.
Thanks again for your generous help.
Jac
p.s. edited, because I stupidly saw your email only a few moment ago...
Jeffrey,
With my very limited knowledge, the strings of 0 and 1 are just clear to me, as I can directly relate them to the bit-strings required for setting up the modulators, as is instructed in their datasheet.
It would require several additional lines of code to translate the settings to the bit sequences, and this is already clear enough.
Jac
Hi Jeffrey
Doing what you suggested probably makes sense particularly if it would need changing a lot. But originally it was envisaged as write once and then forget. Well that would be the case if I got it right first time
. I had a quick look at it and to leave it fully configurable each channel would need 24 individual settings to be set (UHF frequency, divider, etc.) which is quite a lot.
I just don't know is it worth it for the limited amount of times that it will be changed.
To do the System A channels only the UHF frequency and the divider needs to be changed for each channel. The rest remain unchanged.
It is only when you move away from System A that the other settings needs to be changed.
As far as I understand the problem Jac was having was he couldn't turn off the audio modulator from within the channel data sets.
This was because in the program I discarded the bits of the data sets that control the modulator on/off and replaced them with the input from switches SW8A and SW8B on the circuit board. So they could be used to turn the modulators on/off.
If as in #290 the code is replaced with the new code this should allow the modulators to be turned off within the channel data sets or with SW8A and SW8B.
Personal I like binary and never really got along with hex. Back in the 80's I had a Jupiter Ace computer which was along the lines of a Sinclair ZX81. I spent a many an hour on it typing Z80 machine code in binary. No assembler available back then. I cant remember if it was by choice or if it had to be done in binary but since then I have always used binary where decimal isn't suitable. 8 bits in binary are fine but I do know what you mean when you say "looking at strings of 16 bits makes your eyes go funny".
Frank
I've not looked in full detail but I think it would be possible to specify the frequency multiplier as a decimal integer, cast it to a slv and concatenate the result into the programming data.
It's the usual thing of making it easy to understand what you're trying to do and letting the tools do the tedious work. Then when you revisit the design it's easier to work out what you did and modify if needed.
Good news: the modulator(s) work now as I wanted.
After a lot of fiddling, I wanted to start again at the beginning and loaded the commands Frank made.
To my understanding, I now did exactly the same as a few days ago, but lo and behold: it does work this time!
I must have made some mistakes before.
Now I'm going to try to understand why and how Franks file adaption actually works.
In the process I'm leaning a lot. It is also good to have an insight which things are beyond me (well... quite a lot actually).
Several of the answers Frank gave me can be found in the files themselves, once you know what for and where to look.
I can now make a series of frequencies for the 567 line sets.
The back of the Hedghog and the Panasonic TR1001S working at the required 567 line RF frequencies (sound to vision is 4.5 MHz):
[
attachment=18648]
The video still is 625 line of course.
Jac
Studying the code I learned a lot so far, and I now understand some of the modulator code lines.
A lot of the I2C intricacies are still obscure to me, but since Frank has this working perfectly, there is no need for me to get into that. I just enjoy the working as it is.
Since the vision modulator does not require the software switching-off possibility for my applications, I removed that part from the code.
The following now remains:
RF_CF_DATA_SEND(4) <= RF_CF_DATA(4);
RF_CF_DATA_SEND(3) (15 downto 7) <= RF_CF_DATA(3) (15 downto 7);
RF_CF_DATA_SEND(3) (6) <= V_RF_ON_DATA; -- turn off video rf oscillator
RF_CF_DATA_SEND(3) (5) <= V_RF_ON_DATA; -- turn off video rf modulator
RF_CF_DATA_SEND(3) (4 downto 0) <= RF_CF_DATA(1) (4 downto 0);
RF_CF_DATA_SEND(2) <= RF_CF_DATA(2);
RF_CF_DATA_SEND(1) (15 downto 7) <= RF_CF_DATA(1) (15 downto 7);
if RF_CF_DATA(1) (6) = '0' and RF_CF_DATA(1) (5) = '0' and A_RF_ON_DATA = '0' then
RF_CF_DATA_SEND(1) (6) <= '0'; -- turn on audio rf modulator
RF_CF_DATA_SEND(1) (5) <= '0'; -- turn on audio rf modulator
else
RF_CF_DATA_SEND(1) (6) <= '1'; -- turn off audio rf oscillator
RF_CF_DATA_SEND(1) (5) <= '1'; -- turn off audio rf modulator
end if;
RF_CF_DATA_SEND(1) (4 downto 0) <= RF_CF_DATA(1) (4 downto 0);
Thanks again for your help Frank!
Jac
Hi Jac
Well done on getting working
VHDL can be tricky enough to get the hang of. I know as it wasn't very long ago that I was starting off like you. The secret is to keep at it and don't give up.
I would strongly advise you to read through all of Jeffrey's posts in this thread. He gives great advice, tips and examples. I have read through them many times and still do.
Keep up the good work
Frank
Hello Frank, et al,
As I am into vintage TV formats I just bought a French TV9-90UM. I am a little crazy I know...
.
That is the French version of the Sony TV9-90UB which instead of 405 can receive 819 line TV signals on VHF. I got this for later developments in the standards conversion arena... Of course 819 lines is a higher format than 625 so converting up would be only one option but what I would really like to do is convert an HD signal i.e 720p or 1080i to 819 lines.
For an "HD Hedghog" this kind of conversion would need a different approach though.
- An HD input capability for the Hedghog from an HDMI or HD-SDI input interface
- A different scaling approach as we would be going from a higher to a lower resolution format
- Perhaps a different output chip as the current one has an LPF with 9MHz cut off (the French 819 line system has a vision bandwidth of 14Mhz)
For 720p inputs this could be done by generating odd and even fields from the 720p frames with an algorithm that shifts up/down by half a line with respect to the original position to get the interlaced image. For 1080i simply the 1080x540 fields would be converted to 819 line fields.
My question is; could this be done with the Hedghog hardware base by replacing the input TVP5051 decoder by an HDMI or HD-SDI front end? I realize that HDMI my pose some additional problems due to HDCP but I would go for a non HDCP input or HD-SDI which would be my preference...
I realize this is a new subject and just wanted to get some feedback about whether this is feasible. Nothing I am planning in the next few weeks though, just to get a discussion started perhaps in a new thread?
Cheers
Semir
SDI input can be done either with specialist chips such as those from Gennum or with a more advanced FPGA that has high speed transceivers. You're a bit unlikely to find SDI signals in an enthusaist's home.
I've done a DVI input on one product I designed some years ago. The video part of an unencrypted HDMI signal is identical apart fromt he connector. Not too complex though I don't know if the chips I used then are still available.
For either approach you would need interpolation on both H and V axes. For most HD sources you would need to convert from progressive to interlace which is easy if you have a framstore. Impossible otherwise. Much harder if you want a good quality frame rate conversion, such as from 1080/60i to 819.
A few years ago Darryl and I discussed the possibility of an Aurora with HD input. We decided it wasn't worth the effort as you can get cheap HDMi to SD analogue converters. Obviously full quality 819 can't be achieved that way.