Solved: Strange output from mbfm

[Juel]

I have built a minimal mbfm setup with only opl3 and core module.

The problem is that it seemed to be completely silent until I tried it

with my oscilloscope (I didn't use it before because it was hidden

very carefully when we moved last time). (For all measurements

and checks below I used the testtone program.) I found the same

signal on all outputs and it looked approximately like this:

Before providing any data I need to point out that it is a really bad

oscilloscope, only 10 MHz so I was astonished that it even could

trigger on some of the signals I tested. Also all values I mention

should are very imprecise and just approximate. 

The output had a frequency of about 50 kHz and 10 mV peak to peak.

The capacitors worked since there was no DC component. I then

followed the signal path backwards through the op-amps which

seemed to work correct.

Now for the interesting part. The right hand side inputs on YAC:s all

(except TST1 and TST2) had the same signal, a weaker version of the

outputs. I don't know what all the connections are used for but it

seems strange that all have the same values. Also everything was

completely symmetrical over both chips and all channels.

On the other side of the YAC:s I found a discrepancy. The DIN, or

DOAB and DOCD had different values. Both seemed to be digital

and both had a period of 10 us. The difference was that DOCD had

about 0.5 us of 5V and the rest 0V, but DOAB had 2 us of -5V :o and

the rest at 0V. Even more interesting is that this didn't change when

is switched chips, therefore it seems that it doesn't depend on the chip.

Appart from this SMP1 and SMP2 were identical (I just noticed I forgot

to check CLK).

Regarding the inputs to the YMF I have checked it with the interconnection

test and it passed. But still the input looks weird. All connections (except

IC#) between PIC and YMF only had a 15 MHz, 10mV peak to peak sine

signal. Could be a disturbance but it was very steady in frequency and form,

but sometimes a little pulsating in size (probably because of my lousy

oscilloscope as I observed this before). Regarding IC# it was 5V but still

with the same small sinewave overlay.

Next step is the core module, but as the YMF is directly connected to the PIC

I can't test the signal path any further. Still I haven't found any problem

with it . It swallows any upload nicely without any errors. Powersupplies

for both modules work flawless. Midi IN/OUT is "responding" as well. I

haven't checked the oscillator on the core though.

I would be very happy if someone has any idea of what is going on.

Maybe someone knows what signals should be sent or at what speed.

Also the -5V is a mystery to me (I have checked for shortscuts etc. ) and

even more why the final outputs are all the same. If one or both of the

YAC:s is broken they should probably not produce the same result, the

same applies to the YMF as nothing changed when I switched it. It is also

strange that most signals are so very faint.

Again I have to point out that every value I have given is very imprecise,

I would guess that for small time measurements the error is at least 20%.

So I hope this information can be of any use and I would gladly supply

more.

EOF

[stryd_one]

Was this chip also one that you salvaged from a junkpile in the rain?

Have you triple checked that all measurements match the schematic? does the core work without the FM attached?

[Juel]

Both soundcards where salvaged from the junkyard, and both where

inside computerchassis. Also I never use the junkyard as a source

when it has been raining in the last week, except for when I found

a commodore 128. That one I found while it was raining, but it worked

perfectly after 10 restarts (old hardware is amazing, almost like a rusty

old mechanic machine). Actually the only thing i found and tested that

didn't work was a SCSI harddrive that I took from a pc and used in my

amiga. It developed a read/write error quite quickly. Regarding the

chips it seems strange that both produce exactly the same result, which

seems to indicate that either both are working or they have the same

error.

Regarding the second question I am not really sure what you mean, but

I have followed the signal path backwards several times with both chips.

I'm not sure if I tested the core module alone, but at least I didn't test

it with my oscilloscope so I will desolder it asap and come back with info.

[stryd_one]

Well, at first, you can skip the oscilloscope and just be sure that you can upload apps and send and recieve midi and display text on the lcd and light LEDs.

[Juel]

It swallows any upload nicely without any errors. Powersupplies

for both modules work flawless. Midi IN/OUT is "responding" as well.

But I have desoldered the OPL3 module now so I will test again without it.

Last time I only did uploads and it worked well with midi sending in both directions.

I also checked with midiox that it was responding during upload. Are there any

other miditests I could do? Also I tested the interconnections without the OPL-module,

but the result was the same (except for perhaps a little less noise, 1-5 mV or something)

+5V on RC4 (which should connect to IC#) and 0V on the rest. So it could help

if someone know it the PIC sends data continously or just once during the testtone

program.

Finally it is only a minimal setup so I have neither LCD or LED:s. I want to get the

synth working and try it out before I buy the expensive parts for the CS.

Correction: The -5V mentioned above was false, I forgot to switch the scope

to DC mode so the offset was wrong. Sorry

[stryd_one]

Sorry maybe I should just add, I didn't read the big first post, just wanted to get the basics out of the way.

I also checked with midiox that it was responding during upload.

You should use MIOS Studio, smart mode. Search for my posts about it, there are about eight trillion :D

[Juel]

You should use MIOS Studio, smart mode. Search for my posts about it, there are about eight trillion :D

That is what I am using. Even without reading the posts ;) But I can add that

I have some problem with running midiox and MIOS studio at the same time.

Maybe I have routed wrong with midi yoke, but I don't care at the moment. It

works fine when midiox is not running.

[stryd_one]

The point is *how* you use it.

[Juel]

I use it with both smart mode and wait for request.

I have now uploaded mios (1.9f) and testtone(1.1d or something).

The full logs can be found here:

mios

http://juel.homeip.net/midibox/mios/hex_file_upload_window.txt

http://juel.homeip.net/midibox/mios/midi_monitor_in.txt

http://juel.homeip.net/midibox/mios/midi_monitor_out.txt

testtone

http://juel.homeip.net/midibox/testtone/hex_file_upload_window.txt

http://juel.homeip.net/midibox/testtone/midi_monitor_in.txt

http://juel.homeip.net/midibox/testtone/midi_monitor_out.txt

The only thing to remark is the timestamp [unknown] in the output.

I don't know but could it be that there is no midiclock present?

I haven't measured the outputs after I uploaded and I haven't got

time to do it now so I will tell you tomorrow.

[TK.]

This isn't a MIDI or application issue, since the upload works stable.

Unfortunately my MBFM resists at the bottom of my 19" stack, therefore I'm not able to quickly do some scope measurements on my MBHP_OPL3 module for comparison with your waveforms. All I can say for now: noise below 10 mV can be safely ignored!

With a scope you could check the digital interface first.

Use the midibox_fm application instead of testtone for such checks, as testtone configures OPL3 registers only once after startup - so no periodic repetition, hard to measure...

Send some >>different<< MIDI notes, so that the frequency registers will be changed.

Check with your scope: that D0..D7/A0..A1 are toggling depending on note number

that WR is toggling mutiple times whenever a note is played

that RS is permanently 1 (so far I remember...) - it's the low active reset line

No detailed descriptions required from your side for further analysis - it's only interesting if you see the signals toggling... yes? Then you can safely assume that the core is perfectly working.

Btw.: did you already search for older postings where OPL3 modules were debugged. I remember a case where somebody soldered the chips with wrong pin orientation - the pinning can be confusing when you compare schematic with PCB layout, as the SMT chips have to be soldered upside down (-> mirrored pinning)

Best Regards, Thorsten.

[stryd_one]

I use it with both smart mode and wait for request.

Good stuff :) You mentioned using it with midi-ox though, perhaps you tried a loopback cable? I'd avoid that in general, but as TK has pointed out, your logs show that all is well in midi land, so your core and midi interface appear to be working ok :) PS: Thanks for the detailed logs, that rocks.

The only thing to remark is the timestamp [unknown] in the output.

I don't know but could it be that there is no midiclock present?

Don't worry about that. The timestamp isn't actually in the midi signal (like clock) it's just a timestamp of when the PC detected that the message had arrived.

Good luck with the tests!

[Juel]

PS: Thanks for the detailed logs, that rocks.

All information I have given is dedicated to you, since I have noticed that you usually

remark on that ;). But then it turned out that you haven't read it all anyway :o.

(TK seems to think it is enough though.)

Well actually it is not true, since I am a mathematician and know exactly what you

mean in your troubleshooting guide. If you understand the problem it is already solved.

So you need all the info you can get.

edit: The info is also useful for other troubleshooters.

Ok, back to the topic. I haven't tested the mbfm app yet (currently out of electricity

because of some maintenance work). But before that I tested the freshly uploaded

mios and testtone, and the result was different. Apart from RC4 (RS) being 5V now

also RC5 (WR) and RB5 (D5) were 5V (the others still 0V). I am not sure what effects

this will have but I am moving on to mbfm test and then soldering the OPL3 again.

Since I have changed between testtone, interconnction and mbfm apps several times

it seems that it could be the mios upload that was corrupted (I don't recall any error

messages though), or it could be that I uploaded with the OPL3 attached before.

Still both of the cases seems strange.

I'll be back when I have tested mbfm with and without OPL3.

PS. Your info was great TK :). Especially about the testtone app. DS.

[stryd_one]

All information I have given is dedicated to you, since I have noticed that you usually

remark on that ;).

Thanks! Sometimes it may seem that I'm being difficult, but it always leads to a fix....

But then it turned out that you haven't read it all anyway :o.

(TK seems to think it is enough though.)

TK commented after you posted the logs I asked for. The reason I asked for them first, is simple logic - no point trying to fix your FM module, if the core controlling it, is malfunctioning. I needed to confirm that you had checked that properly, before I spent a great deal of my valuable time reading about your oscilloscope tests. You jumped the gun a bit there, and I don't have time to spend an hour reading about your tests if your core turns out not to be working ;) That's the same reason I asked about the source of the chip.

(currently out of electricity because of some maintenance work).

Sucks! Hope you're back online soon!

But before that I tested the freshly uploaded mios and testtone, and the result was different. Apart from RC4 (RS) being 5V now

That one would explain your problem. If it was 0V before, you were holding the OPL3 chip in reset state.

also RC5 (WR) and RB5 (D5) were 5V (the others still 0V).

If WR was stuck low all the time, that was bad. It should change low only when you write to the OPL3

Since I have changed between testtone, interconnction and mbfm apps several times it seems that it could be the mios upload that was corrupted (I don't recall any error messages though),

Exactly what I wanted to test :)

or it could be that I uploaded with the OPL3 attached before.

BTW: that cropped text is really annoying when I'm quoting you!

[Juel]

Working!!!!  :) :) :)

(But noisy, almost like my sidstation.)

I guess it must have been the mios after all.

A bit strange since I know I would have seen

any upload errors. And that the OPL3 module

could have inflicted on the upload also seems

strange, especially since I am quite sure that

it was not connected at that time.

So after all you were right and it was a software

problem. Thanks a lot everyone.

Also a great thanks to my supplier Linneberga

(the junkyard). I think you can guess where I

found my oscilloscope ;), in original box, with manuals.

I don't think it was even used once.

Thanks again

Juel

[stryd_one]

[me=stryd_one]does the "it's working" dance[/me]

Every now and then, a MIOS upload goes all OK with no errors, but something "just ain't right"... Sometimes a fresh upload sorts it out.

Also a great thanks to my supplier Linneberga

(the junkyard). I think you can guess where I

found my oscilloscope ;), in original box, with manuals.

I don't think it was even used once.

Free scope? Are you serious?! SCORE!!

[Juel]

[me=Juel]does not know the "it's working" dance, but he was smiling all

day and felt rather confident until he hurt his fingers with a screwdriver

while fixing a broken fan.[/me]

FYI that fan is still broken and will forever be. >:(

(Not smashed (no hidden anger), but surely disabled. It is also going to

be sent back to my "supplier" for further processing. ;))

About the scope: It is old (1978) and bad so you can't make any serious measurments

with it, but it is a great compliment to a dmm (and FREE :)). In fact I suspected

a bad soldering or something until I saw the waveform. Also I could trace

the signal backwards and I was suspecting the PIC in the end, since the output was

quite meager. But I am not sure I would ever have tried to upload the mios

again without you guys.  :) :) :)

Also I updated my second topic, but I don't know how to change the name to

"Solved: ..."

Thanks

Juel

[stryd_one]

Also I updated my second topic, but I don't know how to change the name to "Solved: ..."

You can click the link to modify the first post, and edit the subject there. Oh - everyone has their own "it's working" dance. You can dance however you want, so long as you dance :)

[Juel]

I lost my sense of rhythm in an unfortunate chess accident,

but I will just wave a bit then, maybe even stomp a foot.

[stryd_one]

I lost my sense of rhythm in an unfortunate chess accident,

Really? :(

[Juel]

I'm not really sure.

Could have been when I listened to my brother playing drums as well.

Btw you don't think this thread is getting out of hand. Just asking since

you are the moderator.

[stryd_one]

LMAO

I cracked up at the first post but I wasn't sure if it was a joke or not...didn't want to laugh in case you like...lost to a thug and had a rook inserted forcibly into your ear ;D

Don't worry about the moderator thing, that's only so I can help out .... As I like to put it: I'm just a janitor, not a boss.

I still get the master key for the building though muahahahah :)

As for the offtopic thread...no problem; your problem is solved, we're not hijacking, just having fun, noone is getting hurt, etc ... all good! I think a little bit of fun chat makes for a friendly forum :)

[Juel]

lost to a thug and had a rook inserted forcibly into your ear ;D

That was the golf accident, but it didn't include rook, ear or ball.

edit: Just removed some stuff that had 30 days archiving period ;).

[stryd_one]

hahahahah :D

Keep doing what youre doing mate.