Hi DC, I forget that a dmm would not provide a correct result, I did know this but head a helpful prod now and a gain. I had been trying to find my Amm as I think this would give me a rough idea of the voltage? And then work out how to send a stream of 11111111 But I have just moved every thing is still in box’s.
I wasn’t going to use the logic probe to check the com port signals, and I had already got the windmill software but haven’t tried it yet, thanks for reminding me about it, I mite give that a go.
Here is the link if any body else wants it http://www.windmill.co.uk/serial.html
Patrick, thanks for the link.
I have booked an appointment!Other than that, I hear there are counselors that can resolve the toughest communication connection problems.
Thanks a lot for helping me hope fully I will be able to repay the favour, james
Hi DC, you're right. I had forgotten that a logic probe works well between 0 to +5V (or +12V), not between -12V to +12V. But what do you think about this little RS-232 tester (I've used something like that 10 years ago :I think it's not so bad) ? Tell me.
I'd wonder if any multimeter will be able to give much information beyond detecting something did or did not change state for a bit stream. The RMS for analog meters is based on a average sine wave, not a square wave, unless it is a true RMS meter. Digital meters should if the signal were stable.
A scope can put out an RMS value as Patrick shows, but I would question its validity, only because the signals are not consistent. As a go/no-go for signal presence, it would be useful. I'd tend to think that value itself is inconsequential. But then the signal viewed on the O-scope would be enough validation for presence.
My suspicions are that if the signals standard from the PC are in the +/-12 volt range(to produce the 20v swing with a 0vdc bias) and the supply for the VM111 is only 12-15v. The signal leaving the VM111 will only be around if not less than +/-6v with a +6vdc bias if using a common ground between the 2 devices. This signal leaving the VM111 may not be detectable by the PC serial port? You should be able to see this if the VM111 makes an attempt to respond on the PC receive line via the scope.
It could be fair to add that the laptop is also running on 12vdc, so this may all be superficial on my part.
This just might put the VM111 signal in the transition region(normally between +/-3v) of the switching state of a com port, which would fail to detect any changes of state on the receive line and/or hand shaking for that matter. Sometimes it might and sometimes not? In this case considering the signal differences, if the two units were connected via an optical isolation module powered by the PC, they may work fine. Just dunno for sure, but I can keep guessing as well as anyone.Heheh!
Apogee Kits Does have a warning that this may not work with some laptops, but do not give details.
I liked that CRT clock link! Too Cool.......LOL!
DC
This is why I thought it was the voltage as I am using a laptop, and I read that laptops tend to have lover voltage on the serial port than desk tops. It also said that there wasn’t really a standard for the serial port on desktops or laptops and the voltage can range some were in-between 5volts ~ 12volts.Originally Posted by One of Many
This is the reason I thought it was the serial port voltage: using the program to it can detect the K8048. When I press the read write buttons on the computer program the read/write LED on the K8048 lights up, but the software says “no device id received” but I have tried this with several different PIC’s
Is this similar to you Patrick?
Those cocks are good if I ever get programming PIC‘s I mite give it a go.
I was browsing a site the other day about CNC and to my surprise it had a link to home made clocks a CRT and there are some good ones made with nixie tube’s
Link more cool clocks: http://timeguy.com/cradek/clocks
You Know DC, I think that the average value of a sine wave (I mean a perfect one : w/o harmonics) is exactly zero. The True Root Mean Square ( = effective value) of the same sinewave is not zero but : U(trms)=U(max)/1.41
1.41=square root of 2
The "RMS" voltage IS ABSOLUTELY NOT the average voltage, neither for a sinewave nor a squarewave. And a good DMM isn't based on the the average voltage (or current...), but on the (T)RMS one. I will develop my point of view (really not mine in fact) later because I first must to think how to explain that...I'm absolutely not an expert in serial devices communications but I think I know a something about the measurement of voltages and currents.
I have used RS232 LED testers too. In some instances the testers themselves can load the port to the degree of absorbing the signals so much so that what is left over is not useful coming out the other end. I have never experience it that I can recall. Although when I use them, it is just for temporary troubleshooting of machine tool communication.
Here is a good link with some details to RS232 Protocol standards which may be useful, if not old news.
DC
You are totally correct Patrick in all respects.
My only point in precaution was that some (older) analog meters if not including the RMS circuitry did do an averaging representation of AC to its DC equivalent. Thereby not a very reliable way to measure true RMS by their nature. Even more so with a square wave, given the duty cycle is not sinusoidal. Those meters were not calibrated or balanced to meet that specification. As I recall some warnings, anything other that 60 cycles would mess with them some too?
A good digital meter with TRMS circuitry does not have this issue for a true square wave or any other pure wave for that matter. Throw in some variable duty cycles within the signal as in a bit stream and the RMS for any one period within that bit stream would become useless information on questionable merit. Yet still proof the signal is there, all be that without proof of its data integrity.
To summarize the way you put it earlier. This is where a scope takes over and a meter leaves off in terms of seeing the signal with ones own eyes. Often times the meter measurements themselves won't reflect what we really need to know. Often, that leaves people scratching their heads wondering what to do with the information they see coming from a meter. Not knowing how to apply it, whether it is relevant or meaningless. That is why the RS232 tester were made. Pretty effective solution to keep it cheap and simple, short of having the luxury of a scope.
RMS and Analog Meter explanations
DC
Last edited by One of Many; 09-03-2005 at 07:17 PM.
Hi J M,
I purhased the same unit, had problems with it also, virtually the same description as to the device appearing to work correctly but not able to detect a PIC present.
Double check your soldering, theres some transistors near the rs232c port connection, I found one that was'nt soldered correctly and inserted the wrong way around, it works fine now
MIke
Hello mike
I’ll have to dig it out from the back of the cupboard, I had given up on it a bit. I will have another good
look at my soldering.
I had a thought the other day when you use the 18 pin socket do you keep the two jumper plugs on all the time? I remember trying to find out in the help file but could find it.
At least I can now rule out the serial port. I made loop back plug which worked and I have also bean programming PIC’s with it using PICAXE.
http://www.rev-ed.co.uk/picaxe/
Hey boys!
Now when we're talking PIC's, check this PIC simulator: http://www.oshonsoft.com/pic.html
--Sven
Pic Programmer
Hi Jm,
If I rememeber rightly I think my soldering on the velleman kit was a bit dodgy around the on board switch, but that did'nt make any difference in the end, I had installed 2 of the transistors in the wrong location. I believe the transistors are there to translate the signal voltages from the RS232c format of 12 volts down to the 5 volts required by the logic circuits, mpu's etc, ( kicked myself something cronic when I realised what I had done).
As for the jumpers on the board, they are required for enabling the onboard timing device for the PIC chips and does require both to be in position on the socket being used to program the PIC's. The only one PIc device not to need this is the 8 pinned version and this relies on the internal osilator.
Best of luck with your PIC programming.
MIke
P.S The only reason I purchased the kit was to program PIC's for CNC controllers. NOt tha I have anything built yet lolol.
hey sven, looks like a good link there, I have been looking for a cheapish piece of software , the original MIcrochip developers stuff is on the expensive side.
Thanks
Mike
There are a couple of Linux open source projects too, I'll install and try these in a near future, http://sourceforge.net/projects/picmicrosim or http://www.dattalo.com/gnupic/gpsim.html
A report will come, any week, any year.
Heeere we go again...
I decided to go for gpsim found at http://www.dattalo.com/gnupic/gpsim.html because its support for many different PIC's. It is a nice program but unupdated and that made the installation a hell, I had to install different versions of GTK+ end its extras, modules, dependencies and the source for popt and...
At least it's up and running. I was too tired to test anything when it was up so I will try to make a little report later on, hopefully christmas will give som spare time to play.
Anyway, I also found this Java-based simulator, http://www.feertech.com/misim/index.html that works fine in both Linux and MS.
There's an old release for free and it was very easy to install, just download the JRE_1.3 package and tadaa! The only thing I did was to edit the bat-file (yes, I did it in Windows) to point out correct Java. It has a lot of different examples and add-on components. Unfortenately the free version only supports 16C84 and there's no price on the newer releases.
--S
Hello,
I have been having the same problem as Mike and j m with my velleman pic programmer. It allways says "no Device ID Recieved"the read/write LED on the K8048 lights up, but the software says “no device id received”
Delay betweenVpp and Vdd
I too was having “no device id received” messages. This shows that the PIC is not going into program mode.
I found the problem to be the way the board switches into Program mode. Figure 2.2, p6 in the PIC16F627A Programming Spec (DS41196E from the Microchip website) shows that Vpp needs to be raised to over 10V and held for 5us before 5V is applied to Vdd in order for the PIC to be placed into programming mode.
The switch that puts the K8048 into program mode rasies both the Vdd and Vpp at the same time. As there is no delay between setting the Vdd and Vpp pins the PIC does not enter program mode.
What the “no device id received” message means (so I think anyway) is the board thinks it has put the PIC into program mode and ProgPIC sends a command to the PIC to reply to ProgPIC with its Id number (and other config data). But as the PIC is not in program mode it does not respond to the command and so the ProgPIC does not get the expected response to the command it sent out, causing the error.
To overcome the problem I had to modify the board. I broke the track between the switch and C8, and connected a BC547C transistor here with its collector going to the switch and the emitter to C8. This now creates a switch that will only allow 5V to get the PICs when there is a signal on the base. I also used a 4.7K resistor connected from the emitter to Gnd to pull down the voltage when the transistor is not conducting - although Im not quite sure if this is needed or if its value is too high but I thought i'd play safe.
Then from somewhere on the Vpp line, I tap off using a 4.7K resistor to the base of the BC547C. Also on the BC547's base I placed a 100nF capacitor with its other end connected to ground. When ProgPIC tells the PIC to enter program mode by setting the Vpp signal to 12V(via 3/9 and the switch being set to Program on the board) this signal is now fed via the resistor and capacitor to the base of the transitor. But because of the setup of the resistor and capacitor there is a delay in the signal at the base being strong enough to allow the transistor to conduct 5V to the Vdd pins of the PICs.
This now works fine for me, I havent tried the board in RUN mode tho as i aint interested in it. The value of the compents I used werent worked out, they were just ones that I had laying around. - But if u use different values, do not go to large as it will put the PIC into program mode too long after Vpp is set and ProgPIC will have already send its commmands.
Before I done this mod I did manage to program a PIC once, but I put this down to a fluke in the way the noise in flicking over the switch finished with Vdd becoming stable after Vpp
Hope this can help someone - my only thoughts are that on my understanding the board supplied cant work. But Im sure there are people out there that have got working models without having to mod it.
No Device ID Recieved
I could solve the problem by placing the correct transistor (BC557 and not BC547) to T3 :-)
Velleman K8084 No device ID received
Just bought my K8084 and had exactly this problem. Could read OK at first but then would not erase, read or write. Problem was the PSU I was using. Regulated 12V - have since used a 15V PSU (borrowed from a lap top) and now works fine.
The velleman appears to be JDM programmer but with internal volatage suppy for 5v and VPP.etc
check vpp IS AT LEAST 13V.
It is still a pin wiggler and less reliable than an intelligent programmer eg- wisp628 etc
what OS and what PC? Lappy? some chipsets stingy on levels and have sleep modes
maybe...
Hi,
I just got my new K808 programmer , but I could not make it work. When I trie to write to the Pic16F627, I get the message "No pic on board|Programmer must be set to PGM mode|PIC type mismatched with software... ", even if the switch is in PGM mode, the Pic is on the right place, and the settings are fine, as well.
I have on the /MCLR pin 12V, on the Vdd 5V and on the PGC and PGM 0V when I get the message.
I made myself the Rs232 cable, I have all the six used lines connected.
What could be the problem??????
Please help!
Posting Permissions
Reply with Quote
