Siglent SDL1000X/SDL1000X-E Electronic Load

[Johnny B Good]

 Now that I've upgraded my SDL to the SDL1030X specification, I've been able to run some thermal management tests, the results of which I think will be of some interest, especially to those who may be concerned about the possible reduction in reliability due to the additional 50% increase in heat output.

 I downloaded the datasheet for the Infeon IRFP250N power mosfets used in the SDL1020X and 1030X electronic loads (same hardware) as shown here:

https://www.eevblog.com/forum/testgear/siglent-sdl1000xsdl1000x-e-electronic-load/msg2533179/#msg2533179

 (third image)

There are a total of ten 12 devices bolted onto that wind tunnel heatsink to share the 310W maximum (I'm currently running a 308 watt test) meaning just 31W 25.67W dissipation per device. From the datasheet, initially assuming direct contact with the heatsink and a total thermal gradient of 1 deg per watt, junction to heatsink, that gives a delta Tj to heatsink of 31 deg 25.6 deg.

 With a max Tj of 175 deg, that means a heatsink upper temperature limit of 144 deg with no margin for error. However, I noticed the use of some sort of SilPad to isolate the 150 volt max input in that image.

 After some research to get some idea of the thermal resistance of a typical TO247 SilPad, the best I could pin it down to was somewhere around the 0.5 deg/W mark so a better estimate of the delta Tj to heatsink at a 31W 25.67W dissipation is around the 47 38.5 degree mark, conservatively 40 deg. A reasonable heatsink upper temperature limit in this case, allowing for an extra 25 deg safety margin, would seem to be 110 deg C.

 Right now, I'm seeing a reading of 87 deg from a K type probe inserted about an inch and a half into the exhaust vent (room temperature some 23.5 deg (+/- 1 deg). This has been constant over the past 45 minutes so it looks like the devices are running comfortably within their thermal ratings with another 15 to 20 degrees to spare on top of that 25 degree safety margin.

 Presumably, Siglent's over temperature protection has taken the worst case scenario into consideration (eg, the two devices at the exhaust end of that wind tunnel heatsink running some 5 to 10 degrees hotter than the two at the fan end due to the inevitable thermal gradient of such a fan cooled wind tunnel design).

 So far, everything is looking good. I measured the power consumption with the load turned off and it measures 11 to 11.5 watts depending on the actual mains supply voltage (typically 238 to 245 vrms). Starting from cold with no load, the fan is stopped and doesn't kick in immediately unless (at 31v) the current is set to 6A whereupon it runs slowly, adding another watt to the base line consumption.

 As the heatsink temperature rises, the fan slowly builds up speed which shows as a smoothly increasing wattage reading on my trusty MetraWatt analogue wattmeter which peaks about 4.5 watts above the baseline consumption for loads going over the 200W mark. From these observations, it's clear that the hardware had been designed to cope with a maximum of 310 watts to begin with. The reduced 210W maximum of the SDL1020 providing an improved margin of reliability.

 One curious observation is that after the heatsink temperature rise has maxed out the fan speed, it continues running at this speed for about a minute 45 seconds after switching the load off before dropping ever so slightly (less than half a watt reduction - it's the change in note that's most noticeable) and then carries on at this speed until, afaict, the heatsink temperature drops to 36 deg, at which point it shuts off completely.

 I've repeated this test, switching off the load when the fan has only been sped up to about half speed. In this case it simply keeps running at this slower speed before the low temperature threshold is reached again, whereupon it shuts completely off as before.

 As far as I can tell, Siglent's design engineers have put considerable effort into the thermal management of this electronic load (more than Rigol's designers seem to have done at any rate) so I'm quite happy with this upgrade hack (at least I can see where the money went).

[EDIT] Just one remaining amusing factoid. I discovered that the mains filter doesn't have a discharge resistor. Accidentally discovered not as you might have supposed - I noticed, after switching it off at its own mains switch, when transfering to a switched mains extension socket plugged into the MetraWatt in order to monitor its power consumption (slightly less than the SDM3065X's 13W btw), the neon indicator giving a brief flash as I plugged it in. Leaving it switched off, I repeated this test by unplugging it, turning the extension socket switch back off and plugging it back in to repeat this brief neon indicator flash test with varying degrees of brightness with only one test failing to show the flash due to managing to unplug it just at the zero crossing point.

 Be warned, you may discover this lack of a safety discharge resistor in a more painful way.

[Johnny B Good]

 I finally got round to RTFM and spotted this nugget in the protections section (page 68 of the user manual) where it states:
=============================================================
Over-temperature Protection (OTP)

The load will enter OTP if the temperature of internal power devices
exceeds 85°C. If an OTP fault occurs, the load input will be disabled and an
OTP warning message will pop-up. When the temperature of the load
decreases and is below the protection point, press any key on the front panel
of the load to clear the error and exit OTP status.
============================================================

 Presumably the main heatsink temperature.

Since I didn't see any such protection kick in, not even in a later test when my thermocouple registered 89 degrees in the cooled wind tunnel side of the heatsink (the OTP sensor is mounted on the outside next to one those powerFETs where it should be seeing a slightly higher temperature), that suggests a significant error on the part of Siglent's OTP sensor calibration unless they've raised the trip point without updating the manual.

 I'm fairly certain that my TC readings are, if anything, a degree lower than actual and even taking the precaution of reducing the thermal gradient from the hot junction into the thermocouple wires by inserting it an inch or two into the heatsink assembly to minimise the classic rookie error of overlooking the cooling effect from the wires on a TC due to poor thermal contact when trying to measure hot surfaces, I'd expect to be seeing a slightly lower temperature than the OTP sensor sees on the hotter external surface of the heatsink.

 IOW, either Siglent played safe with their initial specification and later decided to revise the OTP sensor trip point another 10 degrees or so higher without updating the manual or else it's simply a calibration error in my particular example.

 Has anyone else pushed their SDL1030X to the limit like this and experienced an OTP event?

[Johnny B Good]

 I've been running another 309.5W "soak test" from this afternoon for the past 6 or 7 hours, starting at an ambient temperature of circa 19*C (about half an hour before the CH kicked in). About an hour ago when the room temperature had topped 24*C, I thought I'd finally reached the OTP upper limit temperature with the TC reading 90*C. The odd thing here being no sign of an OTP warning message pop up. It took another 20 minutes of close scrutiny before the penny finally dropped. It wasn't the SDL that was tripping out but my cheap 'n' cheerful Chinese 30v 10A bench supply's OTP kicking in.

 I hadn't noticed that the voltage, as well as the wattage and current readings had been dropping to zero straight away, so concentrated had I been on the wattage read out. The power would be restored within seconds of each drop out and resume for a minute or so before the next drop out.

 In the meantime I had observed the expected 1 or 2 degree drop back in heatsink temperature which seemed to indicate a gradual reduction of the OTP trip point temperature with successive cycles. Even with this big 'Clue by Four', it took a chance glance at the bench supply to notice not only that the current display was showing a zero reading but also that of its voltage output... Bingo! Penny dropped at last (or that Dave Jones' feeling at the moment of discovery that the 10bits setting on an SDS2000X Plus limits its effective bandwidth to just over 100MHz )

 It had reached a temperature of 90*C by the time the bench supply's protection had started to kick in. By the time I realised the true nature of these drop outs, it was tripping out at just 88*C. I shut off the load and switched it off to stop the fan from over-cooling the heatsink whilst I gave the bench supply a chance to cool itself down before resuming the test run with the PSU's voltage maxed out and the CC setting on the SDL lowered to compensate back to the 309.5W setting I'd been running. I also shifted the bench supply a little to give it a little more breathing space which seems to be holding any further OTP events at bay.

 About an hour into the resumed 'soak test' the temperature has finally reached the 200*F mark (93*C at an ambient of 26*C) with still no OTP response from the SDL itself. I've now turned the radiator stat down and opened my hobby room door to share its warmth with the rest of the house and cool down a degree or so. This has resulted in the heatsink temperature dropping back to 92*C (197/198*F), verifying that it had reached its limiting temperature at an ambient of 26*C.

 So, after all of this soak testing, I'm still none the wiser as to exactly what Siglent have set the OTP temperature trip point to. It's clearly way above their claimed 85*C setting but by how much?

 The only new thing I learnt from this being that my modified LW-K1030D bench supply has a reasonably high OTP trip setting (there's no way I'm going to blindly poke a TC into its guts to get a more precise heatsink temperature reading) that does actually work (despite my adding RC filters to the switching mosfet gates to trade a little switching efficiency for a much needed 12 to 15 dB reduction in conducted and radiated switching noise as per this YT video ), with a seemingly narrow hysteresis window.

 BTW, I was a little more conservative with the cap values - 22nF instead of the 47nF he'd used and I'd used small wire ended 33 ohm resistors. I don't have a thermal imaging camera, only an IR thermometer but I did a before and after full load power consumption test to check I hadn't excessively increased the switching FET's power dissipation - a matter of an additional 2 watts consumption versus the extra 4 or 5 watts I'd seen using the 47nF cap values suggested in that YT video, hence my more conservative choice of 22nF caps.

[HamDancer]

Hi all -

I have a brand new SDL1020X-E "upgraded" to SDL1030X (latest firmware). I'm trying to do a battery discharge test while monitoring with EasySDL. Everything works fine for roughly 29 minutes, then EasySDL stops displaying updated data while the SDL unit keeps going fine. EasySDL hasn't frozen (the GUI still works), it just isn't reading from the device anymore and continues to show the last values it successfully read. This has happened multiple times, always around 29 minutes in. To fix it I have to kill the application and power cycle the SDL. The SDL is hooked up via ethernet using the NI-VISA (20.0).

Any thoughts?

Thanks,
Rob

[tautech]

Hi all -

I have a brand new SDL1020X-E "upgraded" to SDL1030X (latest firmware). I'm trying to do a battery discharge test while monitoring with EasySDL. Everything works fine for roughly 29 minutes, then EasySDL stops displaying updated data while the SDL unit keeps going fine. EasySDL hasn't frozen (the GUI still works), it just isn't reading from the device anymore and continues to show the last values it successfully read. This has happened multiple times, always around 29 minutes in. To fix it I have to kill the application and power cycle the SDL. The SDL is hooked up via ethernet using the NI-VISA (20.0).

Any thoughts?

Thanks,
Rob

Yep, these:
Latest firmware is supposed to fix some of these issues so double check the version currently installed and maybe install it again.
https://int.siglent.com/upload_file/zip/firmware/Electronic_load/SDL1000X_X-E_V1.1.1.21R2_EN.zip

[HamDancer]

Yep, these:
Latest firmware is supposed to fix some of these issues so double check the version currently installed and maybe install it again.
https://int.siglent.com/upload_file/zip/firmware/Electronic_load/SDL1000X_X-E_V1.1.1.21R2_EN.zip

Thanks for the response. That was the firmware that was already installed, but I went ahead and installed it again. Also I upgraded my NI-VISA to 21.0. Same behavior - the ethernet interface freezes at 29:27. Just to be clear, the SDL unit continues to work and measure, it's just the data stops going to the PC.

Rob

[tautech]

Yep, these:
Latest firmware is supposed to fix some of these issues so double check the version currently installed and maybe install it again.
https://int.siglent.com/upload_file/zip/firmware/Electronic_load/SDL1000X_X-E_V1.1.1.21R2_EN.zip

Thanks for the response. That was the firmware that was already installed, but I went ahead and installed it again. Also I upgraded my NI-VISA to 21.0. Same behavior - the ethernet interface freezes at 29:27. Just to be clear, the SDL unit continues to work and measure, it's just the data stops going to the PC.

Rob

Reported to Siglent.

For now as a workaround HJK's nice program might work for you:
https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/

Defpom did the SDL description and took some trouble to get it working right however not sure if the same bug occurs at 29 minutes which if it does points to a bug in the SDL itself.

[HamDancer]

Reported to Siglent.

For now as a workaround HJK's nice program might work for you:
https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/

Defpom did the SDL description and took some trouble to get it working right however not sure if the same bug occurs at 29 minutes which if it does points to a bug in the SDL itself.

Thanks, I'll give it a try and report back. I also tried recording just in plain CC mode (instead of Battery) and had the same thing happen at 29 minutes.

Wherever the problem is, I can't seem to reset the connection without power cycling the SDL. I can't disconnect and reconnect from the PC successfully.

Rob

[HamDancer]

Thanks, I'll give it a try and report back. I also tried recording just in plain CC mode (instead of Battery) and had the same thing happen at 29 minutes.

One last gasp - I tried it with the SDL in idle mode (load off) and EasySDL not recording or showing a graph. It still failed after 29 minutes. Just to make sure it wasn't NI-VISA timing out, I used EasyDMM with my SDM3055 and just let it run for an hour and it had no trouble displaying live data the whole time. I think it's a bug in the SDL. I'm rather surprised no one else has noticed this. Can anyone else with an SDL verify the problem?

Rob

[tubularnut]

Just tried it on a native SDL1030X-E, and it logs to EasySDL well beyond 30 minutes.

EasySDL version is 8.5

Firmware 1.1.21R2

[HamDancer]

Just tried it on a native SDL1030X-E, and it logs to EasySDL well beyond 30 minutes.

EasySDL version is 8.5

Firmware 1.1.21R2

Thanks for trying it out. I connected my mine using PyVisa and encountered the same 29 minute problem. Then I left EasyDMM measuring all night and it worked fine with the SDM3055. I'll keep looking to see if I can see something in my environment that could be causing the problem.

Rob

[HamDancer]

Just tried it on a native SDL1030X-E, and it logs to EasySDL well beyond 30 minutes.

EasySDL version is 8.5

Firmware 1.1.21R2

OK this is really driving me crazy, and I'd love some help figuring out what's going on. If I turn on my SDL1020X-E (upgraded to 1030X-E) with FW 1.1.21R2, I can connect over Ethernet with EasySDL 8.5. If I turn on my SDL1020X-E and leave it on for 30 minutes and then try to connect with EasySDL, I get a message that says something like "It's not the correct resource !". If I reboot the computer nothing changes. If I connect and then let it run for 30 minutes, the connection stops returning data. This happens with EasySDL or with a script written in Python with pyvisa. It doesn't matter what mode the SDL is in or whether it's actually measuring a load. Nothing I do lets me connect or measure after 30 minutes. It's such a perfect time delay it's hard for me to believe this is a hardware problem.

Does anyone else have any success or failure stories?

Thanks!

[HamDancer]

Just tried it on a native SDL1030X-E, and it logs to EasySDL well beyond 30 minutes.

EasySDL version is 8.5

Firmware 1.1.21R2

OK this is really driving me crazy, and I'd love some help figuring out what's going on. If I turn on my SDL1020X-E (upgraded to 1030X-E) with FW 1.1.21R2, I can connect over Ethernet with EasySDL 8.5. If I turn on my SDL1020X-E and leave it on for 30 minutes and then try to connect with EasySDL, I get a message that says something like "It's not the correct resource !". If I reboot the computer nothing changes. If I connect and then let it run for 30 minutes, the connection stops returning data. This happens with EasySDL or with a script written in Python with pyvisa. It doesn't matter what mode the SDL is in or whether it's actually measuring a load. Nothing I do lets me connect or measure after 30 minutes. It's such a perfect time delay it's hard for me to believe this is a hardware problem.

Does anyone else have any success or failure stories?

Thanks!

I believe I have figured it out! The problem has to do with having a static IP address. Here's what I found:

• Configure the SDL to have a dynamic (DHCP) IP address. Power cycle for good measure. The ethernet port will continue to work forever (I recorded data for at least 12 hours).
• Configure the SDL to have a static IP address. Power cycle for good measure. Exactly 30 minutes after boot the ethernet port will cease to function (it won't even respond to pings).
  
  • When in this broken mode, switch the IP address to DHCP and then back to static. Now the port will work forever (until the next power cycle).
  • Just to make sure this wasn't caused by something in my environment, I tried it with three different static IP addresses, one of them being the same IP assigned by DHCP. It didn't matter. The port froze in all cases.

@tautech I think you can update your bug report with these additional details. I'm going to guess people don't see this very often because they don't use static IP addresses.

@tubularnut It would be nice to know if you're using static IP or DHCP to see if this happens across units.

Rob

P.S. On an unrelated note, EasySDL is a really bad piece of software. It's full of bugs. I find it hard to believe it's version "8". I hope they clean it up so it's of similar quality to EasyWaveX or even EasyDMM.

[tubularnut]

I’m using static IP.

[HamDancer]

I’m using static IP.

Grrr...

Well I have no idea what the difference is, then.    It's really consistent for me. I've been experimenting for several days. And all my other Siglent instruments work fine with static IP.

At least if someone else runs into the problem someday maybe this will give them something to try. Thanks for checking.

Rob

[Johnny B Good]

 I'm assuming you have an ethernet switch or two in your LAN. I've had experience of strange network behaviour from time to time with a Netgear 8 port Gbit switch over the past ten years or so on rare occasions, obliging me to power cycle reset it.

 Mind you, I can't recall having to reset it for a long time time now since I recapped it about a year or so back. If a bad cap was the original cause of this trouble, it must have gone bad within the first year or two remaining no worse over the next 6 or 7 years before it suddenly got so bad that I had the bright idea that maybe it was time to look for bad caps before scrapping it and make good use of a cheap component tester I'd only acquired a year or two earlier from Banggood.

 Also, of course, you can do the usual troubleshooting such as swap to different ports and trying other ethernet cables (in this case, different ports rather than substituting other cables).

[HamDancer]

I'm assuming you have an ethernet switch or two in your LAN. I've had experience of strange network behaviour from time to time with a Netgear 8 port Gbit switch over the past ten years or so on rare occasions, obliging me to power cycle reset it.

 Mind you, I can't recall having to reset it for a long time time now since I recapped it about a year or so back. If a bad cap was the original cause of this trouble, it must have gone bad within the first year or two remaining no worse over the next 6 or 7 years before it suddenly got so bad that I had the bright idea that maybe it was time to look for bad caps before scrapping it and make good use of a cheap component tester I'd only acquired a year or two earlier from Banggood.

 Also, of course, you can do the usual troubleshooting such as swap to different ports and trying other ethernet cables (in this case, different ports rather than substituting other cables).

Thanks for the suggestions. Yes, the computer and the SDL are directly connected by a Gb switch (the same one that runs my other Siglent instruments). I haven't tried switching out cables or ports because it didn't seem to match the symptoms. The freeze doesn't happen with DHCP, but does happen with a static IP, even when the static IP I choose is the same one previously assigned by DHCP. The choice of static vs. dynamic IP assignment should be transparent to the (dumb, unmanaged) switch. Also if I switch the SDL to DHCP and back to static while it's running, the ethernet starts working again, so that rules out a bad cable. I had originally thought there could be some kind of timeout on my computer - maybe something going into a power saving mode - but all of this rules that out as well. As does the fact my other instruments work fine. The fact that it happens pretty much to the second after 30 minutes after power on is definitely suspicious. My best guess is there's a bug in the SDL firmware where in static IP mode it still sets the same timer it might to renew a DHCP lease, but since it's not using DHCP it corrupts something.

But hey no harm in power cycling my switch and swapping ports. I'll give that a shot.

Rob

[Johnny B Good]

 Well, the first time I experienced problems, it seemed to be a router issue (internet connectivity afaicr) but no amount of soft or hard restarts (both router and even the desktop PC) seemed to help. Power cycling the Gbit switch was the very last thing I tried which eliminated the very weird connectivity issue at a stroke.

 The next time, months later, when my weird network connectivity issue returned, I went straight to power cycling the switch which fixed the problem in seconds. I didn't suffer this weirdness very often, maybe every three to six months or so and whenever it happened, I simply power cycled the switch to restore normality once more.

 Whenever you're trying to pin down weird IP connectivity issues like this, it's always best to "Leave no stone unturned". It may not help in this case but you'll never know until you try it.

[doppelgrau]

Yes, even "dumb" switches can have too much intelligence.
Had once a unmanged switch, where PXE boot didn't work, had somehow filtered some packets in the first seconds after link up...
(TP-Link TL-SG105 switch does not work. The dhcp requests are transmitted, but arp-requests or tftp packets got lost.)

[HamDancer]

Well, the first time I experienced problems, it seemed to be a router issue (internet connectivity afaicr) but no amount of soft or hard restarts (both router and even the desktop PC) seemed to help. Power cycling the Gbit switch was the very last thing I tried which eliminated the very weird connectivity issue at a stroke.

 The next time, months later, when my weird network connectivity issue returned, I went straight to power cycling the switch which fixed the problem in seconds. I didn't suffer this weirdness very often, maybe every three to six months or so and whenever it happened, I simply power cycled the switch to restore normality once more.

 Whenever you're trying to pin down weird IP connectivity issues like this, it's always best to "Leave no stone unturned". It may not help in this case but you'll never know until you try it.

Well I swapped ports with one I know works and power cycled the switch and no change…still frozen after 30 minutes. The fact that I can fix it after it breaks just by switching to DHCP and back to static on the instrument really seems like a firmware bug. But clearly it’s hard to reproduce across units. Also I have three other Siglent instruments on this same switch with static IP and they have no issues.

At least there’s a workaround…it would be nice to get feedback from other people who have tried using the SDL with a static IP so we could see if anyone else experiences the problem.

Rob

[HamDancer]

At least there’s a workaround…it would be nice to get feedback from other people who have tried using the SDL with a static IP so we could see if anyone else experiences the problem.

BTW one nice way to handle this situation is to set up your router to always assign the same IP address to the MAC address of your instrument. This gets you the benefits of a static IP but works around the problem with the SDL (assuming anyone else ever runs across it).

Rob

[tubularnut]

At least there’s a workaround…it would be nice to get feedback from other people who have tried using the SDL with a static IP so we could see if anyone else experiences the problem.

BTW one nice way to handle this situation is to set up your router to always assign the same IP address to the MAC address of your instrument. This gets you the benefits of a static IP but works around the problem with the SDL (assuming anyone else ever runs across it).

Rob

It’s always advised to do this if you are setting static addresses on a device itself, and if you haven’t reduced your DHCP range, as you can potentially get conflicts. I had assumed you had already done this as you seem to imply you always get the same IP address?
But I don’t think this would have been your underlying problem though, unless your DHCP lease time was around 30 minutes to 1 hour. It will still be interesting to see the result.

For me, I have a reduced DHCP range of .100 to .199
I can then use static addresses .99 and below for home devices where I want them fixed, and .200 up for lab devices without having to worry about reserving addresses. Some routers also have a limit on how many addresses you can reserve, but this method gets around that.

[HamDancer]

At least there’s a workaround…it would be nice to get feedback from other people who have tried using the SDL with a static IP so we could see if anyone else experiences the problem.

BTW one nice way to handle this situation is to set up your router to always assign the same IP address to the MAC address of your instrument. This gets you the benefits of a static IP but works around the problem with the SDL (assuming anyone else ever runs across it).

Rob

It’s always advised to do this if you are setting static addresses on a device itself, and if you haven’t reduced your DHCP range, as you can potentially get conflicts. I had assumed you had already done this as you seem to imply you always get the same IP address?
But I don’t think this would have been your underlying problem though, unless your DHCP lease time was around 30 minutes to 1 hour. It will still be interesting to see the result.

For me, I have a reduced DHCP range of .100 to .199
I can then use static addresses .99 and below for home devices where I want them fixed, and .200 up for lab devices without having to worry about reserving addresses. Some routers also have a limit on how many addresses you can reserve, but this method gets around that.

Yes, that's exactly what I do (.100 to .199). I allocate my static addresses below, so I've never needed to do an explicit map in the router before. But my router has allowed me to DHCP-map my SDL's MAC address to an address in my static range, which is even more convenient. This whole thing doesn't make much sense, since the freeze happens when I'm *not* using DHCP. Thus the router's DHCP lease time, etc. can't possibly have any effect. I'm just positing that the SDL has some internal timer with a default value that is doing something unfortunate in the case of booting with a static IP, possibly using uninitialized memory which is why it works on some units and not others. I find it very hard to believe it's something in my environment at this point.

[tubularnut]

Yes, that's exactly what I do (.100 to .199). I allocate my static addresses below, so I've never needed to do an explicit map in the router before. But my router has allowed me to DHCP-map my SDL's MAC address to an address in my static range, which is even more convenient. This whole thing doesn't make much sense, since the freeze happens when I'm *not* using DHCP. Thus the router's DHCP lease time, etc. can't possibly have any effect. I'm just positing that the SDL has some internal timer with a default value that is doing something unfortunate in the case of booting with a static IP, possibly using uninitialized memory which is why it works on some units and not others. I find it very hard to believe it's something in my environment at this point.

Sounds like we have a very similar setup then, which makes it even more of a mystery that STATIC (and DHCP) are ok for me past 30 minutes, and only DHCP works for you??

[kaz911]

Yes, that's exactly what I do (.100 to .199). I allocate my static addresses below, so I've never needed to do an explicit map in the router before. But my router has allowed me to DHCP-map my SDL's MAC address to an address in my static range, which is even more convenient. This whole thing doesn't make much sense, since the freeze happens when I'm *not* using DHCP. Thus the router's DHCP lease time, etc. can't possibly have any effect. I'm just positing that the SDL has some internal timer with a default value that is doing something unfortunate in the case of booting with a static IP, possibly using uninitialized memory which is why it works on some units and not others. I find it very hard to believe it's something in my environment at this point.

sorry to but in - but have you checked if you have a MAC address clash? It is rare- but can happen - and more likely to happen if you have multiple devices from same company - usually of questionable origin..

Check the arp table on your computer as well after it stops - and check if something have changed in your computers arp table.