The Energy Detective Forums

General Category => Developer Support => Topic started by: iteration69 on September 08, 2011, 05:48:10 AM

Title: Can someone from TED Support elaborate please?
Post by: iteration69 on September 08, 2011, 05:48:10 AM
First please speed read this.,499.msg2660.html#new (,499.msg2660.html#new)

I don't remember seeing a MAC address on any gateways. Why wont you guys print a mac address on the gateway? Maybe you need to use something a little better than microchips embedded file system? (that is if mac distribution across firmware upgrades is a problem)

So here I am at work when i discover my gateway is geeked out (due to the subject covered in the above prerequisite post)
So i pull up the statspseg.htm page and i see that the gate claims to be getting packets (but i bet they are murdered to hell and back)
( (

Can you elaborate as to what some of these fields are?  I don't recall seeing this covered anywhere, but i could be blind to the fact. Some of the fields are obvious, such as Pack ID, MAN Cal, MTU ID,  The others can be several different things.

I also check stats.htm
( (

Again some are obvious, some are not. If this is covered in detail somewhere can you please point me to it?

A few weeks ago i was curious as to how much i could learn about the device, I documented some of it here (

I have no idea why all the MTU's are sending at the same time. I tried to bring each MTU up one at a time, at first they appeared to be working but when i got to work and tried to check my use, i noticed that everything is zero again. This is exactly what happened when all the MTUs were sending at the same time. Is your algorithm really this weak?

As i stated in the other post, I will construct a filter when i get home and hopefully that corrects this problem. But for the sake of anyone else with this problem, a little feed back would be greatly appreciated by the majority of your more technically experienced (if not all) customers.  That is, more feed back than "Ok, we appreciate your input"  Think of it this way:  Your internet, cable, or phone has a problem at home so you ask for support. The guy on the other ends reads from a script while you just want to pull your hair out.

Is this the image TED wants to supply? I should hope not. I hope that TED wants to supply an image where engineers or developers retroactively provide support.

If you are from TED and are about to give a canned reply, don't waste my time or anyone else, we will figure this out on our own. However if you are going to provide retroactive support, then by all means please do.

Title: Re: Can someone from TED Support elaborate please?
Post by: iteration69 on September 08, 2011, 01:28:56 PM
Just got home and the first thing I did was check the MTUs. They were not transmitting at the same time as I had seen before.

The gateway was completely geeked out. The led's indicating the gateway was getting data, the web UI did not reflect it, but statspseg indicated it was getting packets.

I grabbed a 33mH common mode choke which I used in my own controllers, i think the dcr is 4 ohms,  low ma rating.  something like 500 ma or so. Tossed a .1uf ceramic cap with 33k series resistor shunted with a transient  voltage sorb ( iirc it's a 180v turn on, 20amp)and filtered out the noise from the mains.  The signal on the MTU / gateway is clean of all noise other than common mode from the neutral.  I read somewhere that the gateway tends to favor the black wire, then red.  All the noise has been removed from L1 to L2. So we'll see how this works out.

In other words after the breaker between L1 and L2 there is a .1uf cap, series wired to a 33k 2watt (it's all i could find near 30k greater than 1/4 watt). The 33k resistor is shunted (ie, parallel wired) with the transient sorb. L1 and L2 then pass through the common mode choke and to the MTU / gateway. I tend to think that a cap on this side of the choke will also attenuate the MTU signal. Ie, the capacitive reactance will shunt the signal-- which is why i did not put a cap here even though a defacto PF filter will include it. In theory some parallel resistance with the choke on this side would be ideal here to help drop the distributed capacitance of the coil windings (effectively lowering the Q) and help balance the line, but i don't know how the MTU <-> gateway interfaces are terminated if they even are terminated.  GAR, if you are reading this, do you have any reason to believe these guys are treating the wiring as a transmission line ?

When i turned the breaker back on everything was confused, transmitting at the same time again. So i pulled the power from two of the MTU's then plugged them back in pausing for a minute or so in between. I watched the lights bounce back and forth and it appeared to be working then they all blinked at the same time,  half a dozen times or so and slowly worked back in to a rhythm, as if they had found a time slot. Figured enough for now.

Everything is currently working at the moment, but that doesn't mean it will not be working in a few hours. I plan to turn on various devices, both inductive and resistive to see what happens.

I'll report back with my results.
Title: Re: Can someone from TED Support elaborate please?
Post by: iteration69 on September 08, 2011, 02:08:16 PM
Turned on the heat pump, stove, and used the microwave. Turned on some highly noisy instruments in the building and everything is still working. No hiccups. Looked at the signals again with the scope and there are still reflections on the line, though not nearly as bad as before. So i assume the MTU and gateway are not terminated well enough, if at all. 

So they are probably not treating the wiring as a transmission line, which may explain these problems. If they did consider transmission line theory I bet they goofed up on a decimal point or used an el-cheap-o component. If this is the case maybe it's not the algorithm or implementation that is at fault-- some firmware developer pulling his hair out and it may not be his problem?

To be continued.
Title: Re: Can someone from TED Support elaborate please?
Post by: iteration69 on September 08, 2011, 10:48:30 PM
9 hours and zero hiccups in the log data. Looking back in the log when shortened the wire and i see all sorts of problems.  Negative values, crazy high figures as if a variable rolled over or a floating point lib has problems.

Obviously my filter is working, and obviously these problems were due to noise / high degree of reflections. Thinking about my previous wiring, in which i simply looped all the excess MTU wiring together in a tight circle of about 6" diameter. I believe this was acting as an air core filter. Add in distributed capacitance, resistance, and inductance and it is very easy to see a natural filter.

My system is working and I don't plan to muck around with it anymore but if someone else is having problems it may be worth while to treat the wiring as a transmission line and attempt to add external termination to the MTUs and the gateway. It's difficult to predict the scheme without tearing the devices apart and evaluating the signal or lugging in a network analyzer. But for starters a parallel resistor across L1 and L2 is a good bet.  The idea here is to basically drop the Q of the line in regards to the unwanted noise. Since the wiring itself will behave as a transmission line, we already have a distributed LCR circuit with air gap core.

Think about X10, if they would have swapped two or three parts around X10 would have had 100x the bandwidth without the BS of zero cross and all the associated damaged from spikes due to the rather large inductor they had to use.

Lastly, it seems that the led on the side of the gateway is very low level. When my system was not working the led on the gateway was behaving normal. So this led is not a fail safe indication regarding signal quality. The only use this led can offer is simply and indication of no communication.  The fact it turns on with garbage data is causing a lot of head aches for people.

Some food for thought to TED engineers/firmware developers.

I use an OSI model with media layer and modified host layer in my controllers.
An led is a status device and I never enable it unless the packet traversed from physical layer through the application layer, to the actual application function with no problems. Then, I turn the active communication led on, and only then.

My packet system itself uses a packet wrapping symbol. The complimenting symbols are boolean logic compliments. My physical layer is a balanced mix of hardware and firmware. Basically the PHY will not allow a packet to be passed on to the data layer unless the packet symbols are correct, and the check sum is valid. This eliminates a great deal of needless processing in the data layer due to garbage packets.

The data layer and network layer are pretty much the same thing in my implementation. Basically, it checks the packet for address and function type(I borrowed the idea of distributed functions and kept physical addressing) If the node's own address matches, or the function type matches a service the node can perform, the packet is passed on to the host layer. Otherwise, the packet is kept in a circular packet buffer just in case the application wants to peak at network chatter.

This allowed me to build detailed diagnostics in to my controllers, one controller may sniff all the network chatter. It served me well during the prototype phases of balancing my system (citing wiring grade, noise level, wiring configuration, etc) I could actually see signal nodes and anti nodes along the transmission line in regards to spatial distribution. A series of controllers all dumping their data layer packets through a packet disassembler, by varying line conditions a few nodes would drop out and the rest would still be showing valid data.