Projects Are Getting Better And Better…

More here: [link]

It feels good my SW is being used by many diyers

…And the Musiland 03 USD

Retail: ~1000 RMB [link]

1 ppm frequency stability

Got to wait for Soomal to see what is inside…

Update:

Soomal just did that: [link]

SOMEWHAT DISAPPOINTED!

The 1ppm clock replaces the 24 MHz clock that feeds the USB controller. The audio-frequency clocks are derived from this clock by the FPGA exactly as before. The new clock brings frequency stability but not necessarily lower jitter because the resultant jitter is still determined by the cumulative jitter of the clock management modules inside the FPGA.

However, there is a new power section consisting of a different LDO regulator (can’t figure out who makes it) and (I think) additional LC filtering?. No doubt this new supply section has lower noise and thus can improve jitter by minimizing power-related jitter inside the FPGA.

Update: The PHKI is an adjustable switching regulator from TI: TSP62200 switching regulator. Thus the use of large inductors. This is certainly an innovation. Switching regulator technology has developed tremendously especially driven by by mobile device industry segment. But I am not sure whether this is better than linear regulators especially the newer breed of ultra low noise regulators. If indeed this configuration is more effective and lower noise to what they were using before, then the jitter performance can be somewhat improved by providing cleaner power to the FPGA.

But, since there is no analog part in this device, it is very likely the I2S lines have been disabled. There are no traces where the I2S lines are located in the other devices. Thus NO I2S lines to tap.

Compare the above photo near C33 (Musiland 03 USD) with the photo below near c34 (Musiland 03 US which has an analog section). Notice that the I2S lines are missing

There is still some more good things: every time Musiland releases a new model, there are improvements to the layout. Notice that in this version that data lines are shielded by ground lines (I marked with blue lines). I believe there are additional improvements in the layout that are not readily apparent.

On the balance, the improvements are positive but I was expecting separate oscillators for the generation of the audio-frequency clocks. I am also not sure about the switching regulators. Seems some of the  newer low noise linear regulators would had been a better choice.

For the diy’er, it would be more fun to start with the Musiland MINI and mod the clock and power section.

New Musiland 01USD

Available on-line (in China): tmall

Musiland is starting to refresh all of their offerings. Here is a photo of the new 01 USD

• Supports USB3.0 power, USB 2.0 high speed interface protocols
• Capable of 32Bit/384kHz audio processing
• Precision clock synthesis algorithm, high-precision timing mechanism for handling ultra-low jitter digital processing. (I think this means they are using the larger FPGA)
• MULINK digital interface (not very useful for us for the time being)
• Uses Musiland  “sixth generation”  USB-powered circuitry to provide a stable, clean power supply
• Driver supports Windows 8 operating system

(I am waiting to see the inside of the Musiland 03 Dragon )

Soomal just published a “first look” article on this device [link]

Indeed, the FPGA and USB chip have been upgraded (Same ones are use in the 03)

The spdif signals are generated by the FPGA and buffered by a TI HCU04 HEX inverter. This is the same as the previous version, but without the output transformers. Probably a good thing, since may diyers replaced the transformers with higher quality ones.

The 1117 regulators have been replaced by these regulators (S5EBI). Can anyone identify these regulators?

Ian’s I2S FIFO Re-clocker: Single-digit psec Jitter

Update (9/12/12): Adding RMS values is just simple addition; peak to peak values add by the root of sum of squares (Xilinx)

Update (9/3/12): updated adding RMS values (square root of the sum of the squares). This makes the RMS jitter numbers for the Musiland devices much better…

Update (8/31/12): updated jitter values after realizing that the FPGA jitter values are specified as peak-to-peak whereas the clock people use RMS values.

Just received Ian’s I2S FIFO Re-clocker from the group buy. Here is novel approach to re-clock an I2S stream with the “absolute” minimum jitter possible.

First of all, I am amazed at the level of professionalism form these group buys…

THE CURRENT STATE OF THE ART: 2-DIGIT JITTER

SPDIF receivers

The venerable SPDIF receiver from Wolfson (WM8804) specifies its output jitter at 50 picoseconds RMS

FPGA-based designs with external clocks

Many in the current crop of state of the art USB-I2S interfaces are based on FPGAs. All FPGA or processor based approaches are limited by the added jitter to the clock whether it is derived inside the processor by a DCM (Digital Clock Manager) or whether the clock is taken from an external discrete oscillator. Once the clock enters the device, jitter will be added.

The amount of jitter added to the clock is typically specified in the data sheets. For example the Xilinx Spartan 3 FPGA specifies the added jitter to a clock signal as it is goes through the FPGA to be a minimum of one hundred picoseconds peak-to-peak. If there is integer division of the clock signal, then the jitter is 150 picoseconds peak-to-peak. If the clock is instead generated internally by the DCM, then jitter is higher, in the order of 250 picoseconds peak-to-peak (a DCM does multiplication and division on a reference clock signal in order to obtain the desired frequency, thus more operations resulting in more jitter).

There are ways to reduce this jitter somewhat by passing the derived clock to the built-in PLLs as described in the Clock Resource Guide [link], but in general, we are talking a minimum of 150 picoseconds peak-to-peak  jitter values. (According to an engineer at Xilinx [link], peak to peak jitter converts to RMS jitter by  1ps RMS =~ 15 ps PP.)

In addition,one must also add the jitter from the source clock. For external, for discrete oscillators this jitter could be as small as < 1psed RMS to several psec RMS. A “typical” audio quality device would have ~ 2 psec RMS of jitter. If the clock comes from another device and not from a discrete oscillator, then one can assume that the jitter is much higher.

Thus the minimum jitter of an FPGA-based board is the added by the FPGA is ~ 10 psec RMS plus the jitter from the source clock. Not bad at all… (There is more jitter added from other factors such as the PCB layout, noise from the PS, etc)

Another current favorite are interfaces based on the XMOS single-core XS-1 device. I was not able to find jitter specification in the data sheet. However, an XMOS processor is likely the equivalent of an FPGA, because they compete in the same space, and one could assume that the jitter performance is similar to that of FPGAs. Thus we can also assume that the minimum output jitter is in the order of 10 ps RMS

FPGA-based designs with internally generated clocks

The Musiland devices derive the clocks from the FPGA clock managers (the DCMs). Two DCMs are used to generate the clocks. Each time the clock is processed by the DCM ~ 250 psec peak-t0-peak is added. Thus processing the clock by two DCMs will add SQRT(250**2+250**2)=24 psec RMS which is still pretty good.

The low end Musiland allows you to use one DCM to derive an approximate clock (good enough for audio) resulting in just 250 psec peal-to-peak of jitter or ~17 psec RMS of jitter.

In addition, there is the jitter from the source clock which comes from the USB chip, which could be in the order of 150 psec pp.  In total, the jitter from a Musiland device using 2 DCMs to generate the clocks could be in the order of SQRT(24**2+10**2)~350 ps p-p, or ~24 ps RMS . This makes the Musiland devices quite a bit better than the well regarded WM8804/05 chips which are specified at 50 psec RMS

Other considerations

There is of course additional jitter caused by noise in the power, circuit layout, etc. So the above is a theoretical minimum. It is pretty obvious that the best devices are the ones using external clock sources rather than internally generated by the DCMs

SINGLE-DIGIT JITTER

Analyzing the current state of the art devices show that the dominant component of the jitter is the clocking device (the FPGA). The goal of Ian’s re-clocker is to lower the added jitter to single digit picoseconds RMS by attacking the dominant source of jitter.

The approach differs from current interfaces by first using a FIFO implemented in an FPGA to receive the data (same as everyone else), buffer the memory in memory (unlike everyone else) and then clock the data out with a clocking circuit that is separate from the FPGA. This way you separate the high jitter (or relatively higher jitter) domain from the low jitter domain.

The clock board is implemented with a simple flip-flop logic circuit and optionally with an additional clock fan-out device if more than one clock is supported. In addition, the clock board is powered by its own ultra-low noise regulators and further isolated from mechanical vibrations with rubber 0-rings.

Thus the jitter at the output is basically the jitter of clock plus the jitter of the flp-flop chip. According to some reports, the jitter added by a flip-flop is just “a few psec RMS”.

There are two versions of the clock board:

The single-clock board

• Single sample rate support (depends on the oscillator used. For example 44.1K SR requires a 11.2896MHz oscillator)
• MCLK is fixed at 256*FS
• 9 uV rms LDOs

The dual-clock board

• Automatic oscillator switching to support all sample rates 44.1Khz to 192Khz
• 9 uV rms LDOs plus enhanced high performace EMI filters

It is interesting to note that the D-type flip-flop in a prototype version of the Dual clock board, uses the PO74G74 which is a breakthrough device from a start-up called “Potato Semiconductor”. You can read the patented technology here: [link].

The shipping version of the Dual Clock board uses 74AUP1G79 (chip marking is “p79″) single flip-flops to re-clock the I2S signal. According to the designer, this device works equally well as the “potato chip” . And in any case we are talking bandwidth capabilities >10x than the highest I2S clock rates on any of these devices

The regulators are Analog Devices ADP151 (“LFJ” marking). You can also see the NFM filters above (the “4-terminal” capacitors next to the flip-flops)

You can see these devices more clearly in this closeup of the matching SPDIF receiver that Ian developed (C9 and the regulator next to c15):

CRYSTAL OSCILLATORS

Since the added jitter by the circuitry is small, the final result may be determined to some extend by the quality of the crystal oscillator. The kit comes with “basic” oscillators to test its functionality. The end-user is to replace these oscillators with higher quality ones.

Musiland 03 Dragon and CD11T

Here is an innovative device from Musiland. The CD transport is targeted at RMB 2000 (a bit over US$300).

The main feature of this transport is the use of a MicroSD card (also known as TF -Trans Flash) to buffer the data first and then played out of memory card in order to avoid mechanical noise (and jitter). In other words, it seems it is an SD card player with a build-in CD reader/ripper. It would be interesting to see what other features it has including what format is the data stored in the SD card…

There is no announcement on shipping date, and I’ve never seen the device powered-on. So probably still in prototype stage.

Slot loading with a large display spanning across the front plate

All possible digital outputs, including the proprietary MULINK. I read that some of the newer self-powered speakers are MULINK compatible so that you can connect the CD11t straight to a pair of speakers.

The MicroSD card can be replaced through the bottom compartment. I wonder if there is a facility to update the firmware. It could be updated through the SD Card. The feet are too low-tech. This must be a mock up device…

24/96K capability. Seems after the data is extracted from the CD and stored in the SDCard, it is then passed through an ASRC for further jitter removal before it is transmitted through the different interfaces. The ASRC function may be accomplished in an FPGA. Musiland’s devices are all FPGA-based.

MUSILAND MONITOR 03 US DRAGON

Then there is soon to be released Musiland o3 Dragon Edition. I couldn’t find any details about it… I read in the forums, that they are planning on using of a more accurate clock, better power section and improvements in the layout. There is also talk of the “03 USD” which is purely a “high-end” digital interface.

And even speakers

Driver looks like an LCao driver

More info (in Chinese): [link]

Full Potential of Buffalo II at Last!

(Hopefully…)

For over two years, I’ve been trying of figure out why I was getting unlocks with the DPLL bandwidth setting at “LOW” and “LOWEST” with I2S input. I had attributed this to jitter from the interface. I’ve tried different interfaces (within my budget), tried modding the power sections of the interfaces, tried using different player software and whatever the audio community was experimenting at the time.

I think I am finally able to use the “LOWEST” DPLL setting without any unlocks. The latest “mods” consist of further shielding and vibration damping. This is starting to look like the type of mods people used to do to their CD players: damping, shielding, power cord/filter mods… I never thought those mods would make a difference…

The reason to go after the DPLL bandwidth setting “LOWEST” is to maximize the jitter rejection capability of the DAC. With this setting you can achieve the ultimate performance that the DAC was designed for.

Although I am not sure how repeatable the results are, here they are nonetheless:

Put some damping material on top of the clock (I think it is some kind of office-type of erase-putty)

Here is the additional shielding: a thin copper plate with two female pin connectors affixed to the plate and plugged into the exposed GND pins of the AVCC module

The following graphs record the number of unlocks per each 10-minute interval for 24 hours. During the first 60 minutes, the DAC will unlock many, many times. During this time the clock (etc) is stabilizing. Diyaudio wisdom indicates that it will take ~one hour for a good crystal to stabilize [link] so this is consistent with observation. Thus, for the Buffalo DAC, it will sound its best at least one hour after power-on

After the “warm-up time, the unlocks are seen clustered in bursts. One burst of 3 unlocks at 9:00 PM (I was listening the music at the moment and they happened within a few seconds of each other). The next two groups of unlocks during the second 6-hour interval and third 6-hour interval were recorded while I was sleeping or away, and they do seem to show up as a burst of unlocks.

I captured more data for another 6 hours (for a total of 30 hours). There were no unlocks in the last 6-hour interval

LISTENING…

After that I did some focused listening comparing the sound between DPLL bandwidth set at MID-LOW (my previous reliable setting) and LOWEST. I used the track “Happy Now” of Poncho Sanchez’s “Conga Blue” album. After repeated non-blind A/B listening sessions, I am able to distinguish subtle differences. In particular LOWEST produces a “sharper”/”less soft” sound on certain instruments (for example, the sound from the cowbell). I think people call this “more focus” and “more layered” music.

More sensitive listeners may find bigger differences, but for me the differences are very subtle. In “normal” listening I would not have heard any differences.

MORE…

The shield a bit modified

Heat exhaust holes

Making sure nothing is shorted by the shielding cage

“LOWEST” DPLL Setting in Buffalo II DAC

[Note: the reader is encouraged to read the previous posts in the subject, to understand the context of this post]

According to the information shared by the designers of the Sabre32 DAC, when you set the DPLL bandwidth setting to “LOWEST” in the Sabre32 DAC, you maximize the jitter rejection capability of the DAC while in its designed-for asynchronous operating mode, that is with the master clock generated by an on board clock, and with the on-board ASRC fully operational.

In theory, there is an optimal setting for the DPLL bandwidth. However, it is probably safe to assume that “LOWEST” in the Sabre32/Buffalo DAC is indeed “OPTIMAL” because it uses a top-end, ultra low noise oscillator.

After being able to identify the cause for unlocks with the DPLL setting at “LOW” (one notch above “LOWEST”) and having implemented a simple shielding solution that eliminated virtually all unlocks, I ran the tests again but this time setting the DPLL bandwidth at “LOWEST”. This is the ultimate test for the capabilities of the Sabre32 DAC as implemented in the Buffalo II and used in my own home environment. The USB interface is the Musiland 03 and the source is a Win 7 laptop with iTunes.

I let the Arduino/computer record the data for 27 hours. Here are the results:

Notice that when the DAC is powered-on, some time is needed for the clock to stabilize and thus the higher level of unlocks (this is normal behavior). Notice also the long stretch without any unlocks.

Comparing with my first set of measurements with DPLL setting at LOWEST, we see that with the casing/shielding fix, the unlocks have been greatly reduced. The graph below shows the original set of data collected during a 5-hour period. The number of unlocks per 10 minutes peaked at over 20. Now there are no data points above 10.

OBSERVATIONS

1. I was totally surprised at the relative lack of unlocks and also at the lack of correlation between waking hours and sleep hours.
2. We seem to have eliminated most of the airborne noise by using proper casing for the DAC. The number of unlocks have been greatly reduced, but at this DPLL bandwidth setting, they have not been totally eliminated.
3. There doesn’t seem to be much noise sneaking in through the wiring as shown by the long stretch of no-unlocks during the waking/working hours.
4. There are two “burst” of unlocks and they coincide in time (8-10 PM). I cannot relate this behavior to anything happening in the house. During the long stretch at night, the washing machine was on and it did not cause any unlocks.
5. I have had the Buffalo II DAC for over two years, and have used different interfaces feeding the I2S inputs. All of this time I thought that the unlocks were caused by jitter in the interfaces, even with the currently used Musiland o3.  Not so!. If we look at the data, the long stretch (over 6 hrs) of playtime without a single unlock indicates that the the jitter in the I2S signals from the USB interface device are not large enough to cause unlocks even at this lowest setting of the DPLL bandwidth.
6. The Musiland 03 seem better than I thought

POTENTIAL SOLUTIONS

1. I can only think of more shielding. Perhaps on-board RFI shielding is required. Something similar to what Anedio has done.
2. I2S isolation. We can use a device such as the NVE IL715 [link]. I already have a device and board and will test it when ready.

ENJOYMENT

Normally, I set up the test and go off doing other things (like going work or sleeping). The test is done with the amp off. Last night for the first time I was able to enjoy several songs (after 10 PM -see data, only one unlock) with the setting at LOWEST. I didn’t even notice the single unlock I measured. I can’t say that I can clearly distinguish differences in sound, but as a diy-audio enthusiast, a successful tweak clearly adds to then enjoyment of music .

3/14/2012 Session

This time I used the computer while listening to music (like browsing the web). DPLL is again set at LOWEST. The unlocks recorded are unrelated to using the computer; they happened while I was NOT using the computer. I can’t figure out what caused the unlocks.

3/15/2012 Session

• I collected data right from the time I powered the DAC for about 5hours. Notice the large amount of unlocks when the DAC is “cold” and the time it takes for DAC to stabilize (“warm up”) – I would say it takes about ONE hour.
• I switched the power cable to a “shielded” cable, keeping the ferrite bead I had before and I also switched the USB cable with one that said “shielded” in the jacket, keeping the ferrite bead I had before. (The original USB cable was a USB-3 cable that probably is also shielded, but did not say so in the jacket). Doesn’t seem to make any differences
• Still no correlation from the unlocks (after warm-up) with what was going on at home
• The pattern of the unlocks indicates interference from somewhere rather than jitter in the USB interface.

Never too much shielding???

Added additional shielding to the DAC chip. To do this, I soldered two pin connectors to a small copper board and then plugged it in to the GND pins of the AVCC module as shown in the photos. In addition, I added some damping material to the oscillator in order to reduce vibrations.

The results: next post…

Sabre32 DAC Unlocks: The Shielding Factor

I have effectively cut jitter in half!(?)

Shielding the DAC virtually eliminated the unlocks (with DPLL setting at “LOW”)

After shielding the DAC with a proper case, I ran the test for 24 hours straight, during which there was a lot of activity at home. Result: I got only two unlocks during the 24 hour period. I will repeat the test again to confirm these results, but this is very good news and has made this simple test tool incredibly useful for tracking down potential sources for noise and interference affecting the degree of  jitter rejection capability of the Buffalo/Sabre32 DAC. I can now set the DPLL bandwidth to “LOW” and thus increasing jitter rejection 2X (see background section)

Just for comparisons, this is the data I got prior to providing proper shielding to the DAC (and with only 19 hours of measurements)

I was very surprised to see that shielding the DAC yields such improvement or that the DAC is susceptible to airborne noise (RFI/EMI) and interference to such an extent.

In any case, the results gives validity to board level shields as implemented by some manufacturers as can be seen below in their Anedio 2 DAC (photo from head-fi)

Other factors to consider: Perhaps the casing configuration I used separating the power and everything else from the Buffalo II board, also contributes to this improvement. Perhaps even affixing the AVCC power module under the board (thus being shield by the GND plane) is also a contributing factor.

SOME BACKGROUND

The Sabre32 DAC has a variable DPLL bandwidth setting which allows adjusting the amount of jitter filtered (or rejected) from the input signal. The (minimum) bandwidth setting depends on the input format (spdif or I2S), the sample rate of the incoming signal and also whether or not the DAC is cold (as in starting up).

While the Sabre32 allows the adjusting of the DPLL bandwidth, there is a point at which the DPLL can no longer lock to the signal. It has been widely reported that for 44/1 Khz sample rate I2S, setting the bandwidth to “LOWEST” will result in unlocks. Users in Japan have reported that the “minimum” (no unlocks) setting for 44.1Khz is “MID-LOW” which is two notches above “LOWEST”. This is the setting that I have been able to achieve with my own setup.

The Sabre32 DAC has the following available settings for the DPLL bandwidth: LOWEST-> LOW-> MID-LOW-> MID-> MID-HIGH-> HIGH-> HIGHEST-> BEST. Each step represent a doubling the bandwidth value. Thus BEST has a bandwidth value that is 128x the value of LOWEST.  Using the “BEST” setting will allow locking into the incoming signal  independently of the aforementioned factors of sample rate, format and whether the DAC is cold or warmed up. Using LOWEST results in the maximum jitter rejection capability the DAC was designed for.

According to the designer of the DAC [link] [link]:

… the performance will get worse as to set the bandwidth higher and higher, since the jitter attenuation is reduced as you open up the DPLL as it were.

…If you choose higher bandwidth setting, the DPLL locks faster but lets more jitter through. Your tradeoff.

I suspect that most (if not all) implementations of the Sabre32 DAC ship with the DPLL setting set at “BEST” because you cannot afford to experience any unlocks on a shipping product. However, in a DIY environment, you can experiment with the different values for the DPLL bandwidth and see the effect.

Thus, if one could lower the DPLL setting from “MID-LOW” to “LOW“, then one could decrease the bandwidth by a factor of two and double the jitter rejection capability of the DAC.

Next: figure out what it takes to use “LOWEST”

Note: see the earlier posts for the full context of these results

Hifiduino with 40×4 LCD

An audio enthusiast from Spain is working on a maxed out Buffalo III implementation (with 4 Buffalo IIIs!), including a maxed-out LCD implementation of Arduino. It is a 4 line/40 character LCD and requires simple modification to the display portions of the code.

You can follow his project here: http://www.audioplanet.biz/t22627p100-the-buffalo-iii-dac

Sabre32 Unlocks: Looking for Gremlins

Recognizing that the Sabre32 DPLL setting is sensitive to incoming jitter, I devised a test to automatically measure the number of unlocks as documented here: [link]

As it is turning out, the unlocks do not seem directly related to the jitter of the transport because they seem random glitches and they show a strong correlation to electrical activity during the daylight hours. Either the noise in the electrical grid increase jitter or causes other anomalies causing the DPLL to loose lock.

In this post I will record and update different tests in order to determine what improves this un-lock behavior. Ultimately, if we can lower the DPLL bandwidth of the Sabre DAC, the level of jitter reduction will be increased, and that is a good goal.

TEST CONDITIONS

• Bufflalo II DAC powered with Placid at 5.25V.
• DPLL bandwidth: “LOW”. This is one notch above “LOWEST” since with this setting I am able to have unlock-free behavior for long periods of time (hours)
• Source: iTunes on Windows 7
• Transports: Musiland 03US
• Everything is plugged into a Monster Cable power conditioner
• [Click on images to see the original size]

MORE SHIELDING: (modding the case)

Originally, I had the DAC board without any casing affixed to the top of the power supply unit, just minimal shielding from a top plate as shown below (minus the Musiland MINI on top which I had upgraded to the Musiland o3).

Using another case for the DAC board (luckily I had a matching case ). I also elevated it from the PS unit below to keep the electronics a little further away from the transformers in the PS unit.

The Musiland 03 also fits neatly inside the case

Never hurts to add additional shielding. I put a metal plate to serve as more shield and to affix the output connectors. In addition, the plate makes contact with the Musiland case setting it a common EARTH GND potential (the Musiland is sitting on rubber feets) with the rest of the case. Also I wanted to isolate the output wires from the input wires.

With the cover in place. you can also see a ferrite I added to the input power to the DAC

Measuring the unlocks…

SHIELDING: SEEMS TO HELP

Suspecting airborne interference/noise (as also expressed by a commenter), I added some additional rudimentary shielding to cover the DAC board (just a metal cover that fully covers the top and the two long sides of the DAC board).

Here I plotted the best data set I had for the wee hours against the new data I got last night. There seem to be improvement. (This time, instead of looping a single song, I let iTunes play through the library -I wouldn’t think this would make a difference)

Notice that I only got 5 unlocks from 11:00 PM to 8:00 AM and there was a long stretch of almost 6 hours  without a single unlock. So we are “getting there”. I shall construct a case that fully encloses the DAC board…

LONG LEADS vs SHORT LEADS: NO DIFFERENCE

I shortened the I2S wires from about 9″ to 3″ to test if there are any differences in the unlock behavior. I also removed the ferrite bead I put in the bit clock wire as it seemed to make no difference (it seemed worse) and in addition, the ferrite might become a problem with higher sample rate material. As shown below, it doesn’t seem to make any difference

AM vs PM: NOISE IN POWER GRID

I let the computer collect more data as I went to work. No activity at home until around 3:00 PM. The Bitclock signal has a ferrite bead (which seems to make it worse – I will test it again without the ferrite bead). As shown by the data: the number of unlocks is strongly dependent on day vs night.

FERRITE IN BITCLOCK: NO BETTER (SEEM WORSE)

Attempted to deal with the power noise issue by inserting a ferrite bead in the bitclock wire (with two turns). The results are shown below. In total I recorded 249 unlocks with the ferrite and 174 unlocks without the ferrite. Since the data was taken in different days, I don’t think the difference is that significant.

What the data shows is a strong correlation between electrical activity during the daylight hours and much reduced activities during the night time hours especially after midnight. There is also a “break” during the daylight hours when people are out of the residential areas.