I do have 2 instances of Limesuite.dll. One is for GDI & 1 is for SDRConsole.
If I still want to keep both programs, ahould I change the name to Limesuite2.dll & all directors in your C# build? Or do I need to remove the SSDRConsole version.
Thank you,
Ed
Link for dll loading order:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Key word is “cache” (Global assembly cache - GAC). Easy check is to rename Limesuite.dll and try C# app. If USB label is always RED no replacement is found. In theory each app can have they own library but always is possible to something go wrong.
73 de yt7pwr
I just coped :Limesuite.dll", then pasted it in the Windows search. 2 instances. Newest, was for Lime# & the older was Pothos (Renamed Limesuite(2).dll). Seems much better. Going shopping & will cobble an HF antenna of some sort.
Ed
@yt7pwr - Goran,
I have three instances of the Limesuite.dll on my Win10 PC…There’s an install from Pothos, one for SDRConsole, and then Limesuite.dll that’s in your subdirectory. What I plan on doing is the following:
1.) Rename the Pothos .dll to something else temporarily (like Limesuite1.dll)
2.) Rename the SDRConsole .dll to something else temporarily, too, like Limesuite2.dll
3.) Reset the PC and allow it to reload
4.) Start LimeSDR# and see how it goes.
I haven’t had time over the weekend to play with it because of some renovation work I’m doing, but I plan to work this later today after work. Please let me know if the above procedure is appropriate and I’ll let you know my findings. I will say that there’s size differences in all the Limesuite.dll files which leads me to believe that not all Limesuite.dll files are created equal - not sure if that’a bad thing or not, but it would seem like Limesuite should be unified (untouched) since it’s a Lime Microsystems development and the authors of apps should have any differences they need in a .dll that does not rely upon Limesuite.dll - - some other dll in their application.
Anyway, I’ll try this later - let me know if you see any potential hazards with the above procedure -
73 de Marty, KN0CK
Marty, I renamed the other instance of Limesuite.dll. Worked better. Still a bit quirky, BUT, I am still learning. Tonight, I will try to throw a wire out & hook up the MFJ preselector. That way, I can test HF. No pink screens on HF as far as I saw. No HF signal, due to an HT antenna screwed to the LimeUSB.
Ed
This begin to sound like “dll hell” 
In the next release I will change Limesuite.dll into something unique to resolve this issue. Additional problem is DLL two different architecture (32 or 64 bit). My app is 32bit and because C# do not allow mixing any exe or dll with different arch exotic app behaviour is possible.
Now I have a question for experienced LimeSDR user: yesterday while I was experimenting funny thing happened - reception went totally dead! I set NCO limit to 30MHz and with only 1536KS/s I was able to tune down to 5.4MHz. And then only one start-stop sequence kill the receiver! Board reset will not help, USB cable unplug, PC restart… Nothing. FM broadcast works fine but HF not. Due to late hours I leave problem for tomorrow. This evening receiver works fine with yesterday settings! After 15-20 minutes goes deaf again. Board was pretty hot and after just few blowing over FPGA receiver came alive again. Is overheating common to all boards and what kind of cooling to apply?
73 de yt7pwr
I got small heat sinks for all chips on the board to epoxy on, as it will see some high usage. Mine gets pretty warm in the enclosure.
Any possibility of an x64 version?
THank you,
Ed
My ambient temp is 10C with fans blowing over the Limesdrmini temps report 50C so they do get warm gonna find some heatsinks for mine
@yt7pwr - Goran,
I’ve had my LimeSDRs on for hours and never had it shut down for any reason due to heat - so that’s not a factor, probably some other interaction in the code caused the abrupt shutdown.
I, too, am looking for a 64-bit version since my Windows 10 install is Pro, 64-bit. Is there any way you can compile for Win 64? Please advise -
73 de Marty, KN0CK
I just aded temperature reading and it shows 45C with disrupted NCO at 1536KS/s. At 40C it start to work normally. I will look tomorrow for heat sink.
About 64 bit version: there are no any significant advantages in term of application speed. Any Windows will run 32 bit .NET app smoothly without user intervention. Currently I’m developing on Win10 Home x64.
73 de yt7pwr
@yt7pwr - Goran,
The application will not work. I tried to isolate the LimeSuite.dll issue and the program still does not operate normally or smoothly even when the LimeSuite.dll in your Release subdirectory is the only .dll that is active after a fresh restart (renamed all the others to the procedure I wrote about this morning). In fact, the application began to react worse as the MOX and MON buttons were both illuminated even after several attempts to turn off the MOX feature so I could MONitor - just kept starting and stopping and starting and stopping erratically to the point I could not use the receiver. Also, the issue with not being able to start in HF is still and issue - If I try to start at 10 MHz, the waterfall is pink. It’s not until I tune to a 2m or 6m frequency above HF that I can then tune to HF, but the receive is choppy - starts and stops and the waterfall is not running, too.
I hope this program can become more smooth and predictable soon - Love that user interface but the program is just not operating right - hate to say that, but that’s my findings. Keep working it, Goran,
73 de Marty, KN0CK
Update is on Github. Only 32bit version is working correctly (x64 is not stable and do not waste your time for now).
HF issue is mainly because high LMS7002 temperature. I added current temperature value in the program caption with 1 second interval. When my board start to work (1536KS/s, 16384 samples) it shows 31C and can rx/tx down to 5.4Mhz for few minutes until temperature reaches 43C when the noise floor goes high up. After short cooling everything is back to normal. Second HF problem was bug in software (, or . for decimal symbol from regional settings). If you still experience this issue try to change decimal symbol to . in ControlPanel->Region. When decimal symbol is changed database.xml must be deleted!
Unresolved issues: I was not able to run TX on any higher sample rates than 1536KS/s. Reception is working fine but when I try transmitting (HF or VHF) app random freeze in unknown module. Because I do not have debug version of Limesuite.dll I suspect that this is where the problem is. As my understanding all wideband tests (WCDMA) with Limesuite is generated from FPGA not sended from PC? SDRangel do not use official driver? Is there any app that can actually send data from PC via USB using BULK endpoint in real time at high sample rates?
73 de yt7pwr
@yt7pwr - Goran,
Tried the 32-bit version of the application and while it does start up correctly at 144.000000 MHz (I see the spectra and I hear static in the speakers along with a spur at 144 MHz), I used to be able to switch to 152.475000 MHz and hear my local weather station. When I do this now (entering the frequency in the LOSC field (like I used to do all the time and it worked) the program crashed and I was unable to do anything outside of just staying within the 500kHz of bandwidth of 144.000000 MHz (tuning to each edge). I cannot tune outside of this without the app,lication crashing. And there is no HF tuning at all - tried tuning to 7.000000 MHz and it crashed. Tried pressing the button for ‘40’ and it crashed - so the app still needs a lot of work there.
That’s my report on the latest version - keep plugging away at it. Goran,
73 de Marty, KN0CK
Try it again Marty. I never use direct frequency typing and did not find error in typing procedure but in automatic stop/start if central frequency is switched HF<->VHF. Now it will only stop and must be manually push Start button again. If this fix do not help I will try next week to visit owner of the LimeSDR board and test several more boards behaviour.
Try first to switch bands while program is stopped. If settings are correct then Losc text must be white.
73 de yt7pwr
@yt7pwr - Goran,
Okay - I did what you wrote and attached my Lime, started LimeSDR# clicked on the ‘40’ button for the 40m band, clicked START and…got a pink waterfall even though the USB indicator shows green (operational). I tried this same procedure 3 times and had the same result - pink waterfall, green USB indicator.
So I then switched to the ‘2’ for the 2m band (with START off) and then pressed start - LimeSDR came right up no issues. Pressed the START button again to stop the program, switched to the ‘6’ for the 6m band, pressed START, and it came up fine - no issues. Pressed START to stop the program, switched to ‘40’, pressed START one last time and…pink waterfall, green USB indicator. So then I tuned back to the ‘2’ for the 2m band, pressed START and it came right up. Pressed the ‘40’ button for the 40m band while it was running and it crashed.
So the program is still non-functional. Please keep trying - there’s been no improvement and it used to work where I could try to tune 40m after pressing the ‘40’ button while I was in the 2m band. That functionality makes the program crash now.
73 de Marty, KN0CK
Just one more question: when you jump to 40m band what is the color of the Losc text? White or Red?
73 yt7pwr
@yt7pwr - Goran,
White - just like it is in 2m when it’s running…Just pink waterfall and no activity even though the USB indicator is green.
Keep me advised - 73 de Marty, KN0CK
I would first jump from VHF to 10m band. If this is not working then it is pointless to try lower bands. I’m just testing x64 bit version with latest Limesuite.dll from Pothos package and VHF is working fine (rx and tx) but NCO algorithm is not working at all! After some investigation it turned out that NCO function call parameter is reversed!? Also only works TX channel 1.
Few minutes ago I uploaded x86 and x64 version to Github.
x86 link: https://github.com/GoranRadivojevic/LimeSDR-/tree/master/bin/Release
x64 link: https://github.com/GoranRadivojevic/LimeSDR-/tree/master/bin/Release%20x64
On 64bit version temperature readings are 10 degree higher, GDI+ is broken (Waterfall is not working), RX must be set to channel 0 and TX to channel 1.
For both version still remains problem with TX sample rate higher than 1536K: app crash after about 20 sec no matter what I do.
73 de yt7pwr
I;m sorry that I have not had time to help more. But, I finally got the touchscreen working correctly.
My LimeUSB is at work, so I cannot try it with the new software. But, the buttons are now selectable via the screen.
I will try to get it all set up at work in the morning.
Ed
@yt7pwr - Goran,
Any updates on the LimeSDR C# application? Please advise at your soonest - thanks,
73 de Marty, KN0CK