Most recent activity
-
Tue 2020.05.05
I've done one better. Here is what I see in each of two twenty second clips. I think you'll agree that isn't how it should be working, right?
In the first pass trace takes about five seconds and I note that the it outputs it's pound ID references up to around ~#600. During the second pass, as shown in the clips, the IDs are now in the thousands, and it takes more than ten minutes to output at which time noting the repeating data, I just abort.
As it appears your Linux developer station is unable to replicate, lets verify that. Follow the last sequence of steps in #4 post, placing ten or more carriage returns between each step so that I'll be able to examine quicker, but for the first file, don't include the last trace(). That'll create around 100K which will be able to be captured from the console using the mouse drag select process. Should the error be there, then performing the last trace() will need at least two more passes, to grab anything of use, but it will push the first steps North, the reason to save that content first.
With that, I should be able to point to exact lines within your file, and then show a line by line comparrison in my file. We'll then know if it is a Windows only or reproduceable on Linux then.
-
Sun 2020.05.03
Thank you for making the observations and taking the time to poke around a bit. Three points to review, and to make sure we are both communicating.
Is the voltmeter an analog needle type or a digital LCD type? Black ground and Red positive probes?
Regarding R18
If one takes a look at the schematic upper right, R18 connects one side to the positive rail 11V and the other to supposedly the end of a potentiometer. The trace exiting to the left runs down to X2-4 MK where the drawing of the emitter is now connected. I say supposedly, under the assumption the resistor running E-W just above KE and below the silk screen C16 is the 180 ohm (brown-grey-black with black zero multiplier - color too off to be sure) appears to connect to the wiper of PK2, as it is immediately centered between the tabs of PK2, those being just North of the pot itself. Having access to the underside would be nice to verify but isn't necessary. So, electrically, the screw terminal MK is the same point as where the vertical trace in the schematic connects to R18. Then placing the black ground probe to MASA and red positive probe to MK should provide est 6-9V which is actually the drop across the pot, but would provide the value at R18. Would like to confirm so that we know what the transistor is connected to and the range it will be swinging.'Just to confirm, the X2-1 will be the black slot with label "1" on top'
I'm glad you pointed this out, as I didn't double check the schematic terminal block X2. The schematic seems to be for the board with the blue terminal block as it has eight pins. The photo with the black terminal block only has seven. It appears that is a variant or a knock off of the original. Double checking the schematic, I missed that X2 has eight pins, but the board only has seven screw terminals. The big mystery, where is the positive 11V X2-1?
Glad you pointed that out, but don't have a good idea where to get at the 11V yet. I'll continue to study.
Now the two black wires dropping down from the transformer are the input to the AC section which is mostly the parts to the lower right of that circuit board. D1-D4 are the bridge rectifier converting the AC to DC. The labeling 1 and 2 are likely what we see on the left side of the schematic as X1-1 and X1-2. (also not exactly matching) Putting the voltmeter in the AC position on a 20-50VAC scale and on each of the black wires will probably show est 12-24VAC as a S.W.A.G. (silly wild arse guess) and would a connection bewteen MASA and that pin 1 been made, wouldn't have been wise and we might have seen you in the next ElectroBoom episode as we would have been grounding one side of the inbound AC wave. Electrons would not have been happy. Very excited though! Depending on the meter type and which scale it was on, might have damaged it.
It's likely that C16 and R17 are part of the five second delay you mentioned with PK2 adjustable for that delay interval.
Curious, what is the voltage between MASA and X2-7 MU ? (11V ? maybe)
As that pin is connected to R15 180 ohm and then to the other side of the LED, (which by the seems to be labled backwards as the anode side is to ground, so I don't see how it could ever illuminate - me thinks schematic backwards) we may be able to use that as the trigger point for our base resistor input. For an NPN we will need a positive voltage greater than the drop across it's emitter to turn it on, the equivalent of when you were just using the jumper. The emitter would need to connect to MASA though and it's collector to MK at around 6-9V When the transistor is on, we'll have 11-0.7V / 180 ohm or 57 ma current through it. Just over a half watt, but a brief interval, shouldn't be an issue. But R18 in the photo looks like just a quarter watt, can't be sure size wise. -
Sun 2020.05.03
Good Evening Marek and I realize this might not get to you tonight.
'the AC standards is 230 V / 50 Hz'
Well, that explains that humongous square boat anchor next to the fuse holder! Now when we brush up against 120VAC, it is annoying. I imagine you only ever touch 230VAC once!!!
'think there is no standard and engineers just make it up as they go'
Isn't that what they always do? They earned the piece of paper indicating they learned all the maths, so their right? ;-)
Do you have access to a voltmeter?As there is R18 180 ohm resistor connected to X2-4 MK then there should be around nine volts or so depending on position of PK2 10K ohm.
Initial impressions are that the collector and emitter are reversed in that diagram. I need more time to study.
See heading 'Transistor Switch' halfway down page
X2-4 MK would be connected to where the LED is in the diagram the collector. The emitter would connect to X2-6 MASA
R18 should protect the transistor collector, otherwise we may need an additional resistor there. Make the resisitor on the base 5K to 10K or something around that. Then don't connect to the Espruino MDBT42Q just yet. We'll connect a piece of wire in place of the Espruino, our human version to that base resistor and just touch it between X2-6 ground and X2-1 the 11V supply. This should toggle as if you were using the wire only method. Lets get that to function without smoke, then off to the fun part connecting the Espruino and writting code.
@allObjects would you agree on that assessment? I'd use a generic NPN 2n2222 as there are inexpensive. (or T5 BC550 should that be common) I know you always have the best diagrams, otherwise I'll have to resort to your famous ASCII method.
If that doesn't pull X2-4 MK to near ground, then we may need a slight modification to where the collector is tied to.
-
Sun 2020.05.03
'Do you have the actual code and steps to create the error'
Ask and ye shall receive . . .
The following is a challenge to @Gordon, @allObjects, @AkosLukacs, @MaBe, etal to reveal possible reasons for this anomaly before actually reading on, and no peeking with tools or accessing the console until some thought is given. Game anyone?
When performing your individual test, it will be necessary to modify the code file to supply your known IP and p/w - Espruino WiFi required
Use the online WebIDE first, to also observe the corrupt console Window. Caveat, my tests are only on Windows10, so it could be that this is only related to MS. Same results with native .exe WebIDE.
Symptom: Performing a trace() loops indefinitely.
Do the following:
- Load code file codetinyMQTT20200503FORUM.js
- execute function c() in order to connect - wait five seconds for "connected!" response
- *(should the response not occur, don't continue as results will differ)*
- execute trace() and observe the endless loop
Why would the following code snippet cause the symptom above?
var server = "192.168.1.70"; //var server = "127.0.0.1"; //var server = "0.0.0.0"; var mqtt = require("tinyMQTT").create(server); //mqtt.connect(); // Connects on default port of 1883 mqtt.on("connected", function(){ console.log("connected"); }); var wifi = require("Wifi"); function c() { wifi.connect("2WIRE", {password: "33212052"}, function(err){ if(err) { console.log(err); } else { mqtt.connect(); console.log("connected!"); } }); }Syntactically nothing. So before reading on, what might cause trace() to loop indefinitely?
No peeking - withdraw and ponder for an hour before continuing okay?
Okay, you peeked. Now, while I might concede that extra steps may/should be used by the end user/developer before final implementation, I took the examples right off the site tutorials and plugged away. Others might/will do the same.What I discovered may/might also be the reason for my 400 JsVars of memory just evaporating (see rationale later), but won't be able to confirm until this is resolved.
Now, before peeking, I originally thought this to be specific to tinyMQTT as there is an outstanding GitHub issue #1583, but what is there, isn't related to the conditions here.
So, lets try just a basic http fetch, without MQTT- Load code file codeWiFi20200503FORUM.js
- execute function c() in order to connect - wait five seconds for "connected!" response
- *(should the response not occur, don't continue as results will differ)*
- execute function g() to allow a get fetch of the resultant text file
- execute trace() and observe the endless loop
Before moving on to review of the output, realize that I have had intermittent issues for over two years, and I am pushing the memory limits of Espruino to be able to use the WebIDE console as an interactive interface for users. This means lots of console.log() statements, and the need for short function names to avoid having to type things like process.memory() out every two minutes.
To get around that I've been using a short function name for common commands. Stuff like s() for setup, r() for run, t() for test, v() for verify, w() for watch, p() for process.memory().
Now ask yourself what is the pattern here that would allow those to work, yet with the same practice, is now problematic?
Think about that before taking a peek at dump() and trace()
Now, the proper sequence to reveal needed detail as one will discover is to:
- reset(1)
- Load code file
- dump()
- trace()
- c()
- dump() - this is where the observant will gain the insight
- g()
- trace() - opt as will loop endlessly
So, figured it out? - surprising, isn't it!
Reviewing:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var
and specifically heading 'Initialization of several variables'
var x = y = 1; // Declares x locally; declares y globallyconfirms what I had observed a week ago.
View attached file 'wifi.connect.txt' for unminified detail
If one takes a peek at the .connect function() and yes, reverse minification is a real pain, even with online tools, I believe I've found the culprit, but wanted to provide the opportunity for others to discover also.
I've spent nearly a hundred hours testing and comparing just to identify what is happening and have 6Meg of data comprising of around three hundred dump and code files, should any of that be required. Why so long you ask? Well as the console either locks with a low memory situation or as in this case trace() causes an endless loop, it is not possible to get at the console to peek around. So, developing a technique ahead of time and comparing with a ton of data was the only way achievable. Now that I have discovered a repeatable situation, it is easy enough to build your own.
GitHub issue #1811 Anomaly in deployed module corrupts user namespace global scope #1811
Case revealed, but not solved.
Pardon me, back to a twelve year Rye I've been sippin' on . . . .
-
Sun 2020.05.03
Good Morning Marek and thanks for posting the images, I'll need to put a bit of time in to study.
What a treat, the link to the ElectroBoom channel. No I haven't seen that, but just took a quick peak at the channel intro. See a pattern here, First blowing up electronic products, then blowing up oil tankers, what's next?? Having a daily dose of those will make things more bearable!! ;-)))
A quick peak at the schematic and we are dealing with 11V there, so we'll need to be extra careful before connecting our precious Espruino. What an odd value, eleven. What is your mains voltage in your country? We're at 60Hz 120VAC and 5V and 12V are our usual standards. First time I've come across eleven.
The photos really help, any chance you could post one (or a really well understood label reference) of the actual wire you use and where it is bridging pins please. I imagine its on the black or blue terminal block. Where is the lock in the diagram and which pins is that connected to?
This will help others, and I know there are a few forum posters on your side of the world that are heavy into electronics and may have the rest of their day to help out, and I wanted to get this posted to allow a bit of time to get the jumper image posted for them.
P.S. make sure the photo is taken with the power off, otherwise I'll be watching your surprise on that ElectroBoom channel !! wink, wink
-
Marek, did a bit of digging and came up a few ideas.
The suggested MOSFET wiring in #6 post is not correct. From what you have described, it is most likely the lower set of four, upper left image of the P-Channel design you are after where the intercom is the load.
It could be as simple as setting the pin mode and providing digitalWrite() but after reviewing intercoms with a transformer coil (ref #6 post) implies a higher than required secondary and likely modulated or clipped AC.
Referring again to p.151 of the spec, it will be discovered the GPIO pin cannot survive that voltage nor would it be able to drive enought current.
One of my favorite learning videos is the exploding LED, around 03:08and likely what might happen to the MDBT42Q
Other ideas might be use of a relay or opto-isolator. Tutorials thre also.Without the schematic of the intercom, we are just guessing and that most likely will lead to the unfortunate, unrecoverable 03:08
Any chance you could provide images of the exposed intercom wiring and how the shorting of pins is done?
-
digitalWrite() better choice over analogWrite()
Have to step out for a bit, what time zone are you in so I know if I'll have enough time to answer tonight? Me CST [GMT-5] I'll re-read your last post then.
In the mean time, Check out:
Heading 'Transistor Switch'
halfway down the page:
Wed 2020.05.06
@Gordon, and your output is also taking ten minutes and that is normal for a ten+ lines of code? Why does it take five seconds the first time but ten minutes the second? Please provide the output as I requested in #6 post and I'll show what is being missed. The twenty second .avi file capture was over 500M. Ten minutes of output would be 15G.